Take Control of Your Application Security – DZone Security


Bob, the software architect, and Alice, the SecDevOps engineer are part of a growing software development start-up company. Here is the conversation between them on developing a new set of microservices.

Bob: Did you hear the announcement? The client deal was finalized; we can begin the development of an analytics app for their financial services on the cloud.

Alice: That’s fantastic! Which programming language should the app be built with?

Bob: That’s yet to be decided. It can be based on any software programming language, but what’s more important is it must be secure. All our systems and their applications should be up to date with security patches and software versions should always run with proper configurations.

I’ll email you the detailed business use cases and technical requirements. In a nutshell, it will be rapid development with continuous integration and delivery. 

What tools do you recommend for our end-to-end security scans?

Alice: Sure, I’ll send you a list of tools that will enable us to have vulnerabilities detected and remediated prior to production deployments.  I agree we need to have a promising way to scan and eliminate any kind of cybersecurity risks that our code or application may pose.

Bob: Great, our preference is for open-source scanning tools, but do list your insights of popular third-party proprietary tools if any.

Alice starts to explore various existing resources on code scanning topics. Based on the requirement spec received from Bob, she considered all the key areas like static analysis of code, dynamic analysis of internet-facing UI and API endpoints, and vulnerability scanning of dependency packages.

A few days passed, but she is still puzzled and confused and is unable to decide because most of the information out there is based on the user roles, and software availability specifications rather than code-centric, which is useful from a development perspective to fit the need.

Read below to get insights into individual security scanning tools (just enough to help Alice decide).

Categories

Following are the various categories of scanning:

SAST (Static Application Security Testing), aka Static Scanning

  • A white box testing process for analyzing application source code to identify sources of vulnerabilities; is generally implemented at the coding/QA phases of the application development life cycle, thus enabling early identification and mitigation of vulnerabilities in the code
  • Ensures application is built in a strong and secure way from the design phase and is compliant with secure coding standards before it goes to production
  • Some of the tools that offer SAST are SonarQube, App Scan, IBM Code Risk Analyzer, Fortify Static Code Analyzer, WhiteSource, and more. 
  • Commonly used evaluation criteria before using a SAST tool are:
    • Support for required programming languages
    • False-positive rate
    • Vulnerability detection accuracy
    • Level of details
    • Clarity in the outcome of code security analysis

SCA (Software Composition Analysis), aka Dependency Scanning

  • Process for tracking open source components in a codebase to detect vulnerabilities, potential security & license compliance threats, and enables teams to remediate early by avoiding conflicts with IP, reputation, and monetary aspects
  • While static scanning detects vulnerabilities in proprietary source code developed in-house, Software Composition Analysis (SCA) does the dependency scanning to identify vulnerabilities in open source dependencies, discover deprecated dependencies, and evaluate digital signatures. It creates almost zero false positives and scans very fast. Access to source code is not required and can be integrated at any phase of SDLC even postproduction deployment.
  • Some of the tools that offer SCA/dependency scanning are WhiteSource Software, GitLab, GitHub, Snyk, and Jfrog Xray. 
  • Commonly used evaluation criteria before using an SCA tool are:
    • Knowledge database of open-source components and their vulnerabilities
    • Support for various programming languages
    • Speed of the scan
    • Ease of use of the reported outcome of the analysis
    • Integration capabilities to various phases of the development life cycle.

DAST (Dynamic Application Security Testing), aka Dynamic Scanning/Web Application Scanning

  • This is a black box testing process for identifying vulnerabilities of the applications’ web endpoints through penetration tests and with no access to its source code, typically performed during QA and pre-prod phases on the built application. It explores its running state and examines its responses to simulated attacks made by the tool which will help determine whether the application is vulnerable and could be at risk of a real malicious attack.
  • Best suited to detect authentication and configuration issues; independent of language and platform used for application
  • Some of the tools that offer dynamic scanning are OWASP ZAP, App Scan, Netsparker, and Detectify. 
  • Commonly used evaluation criteria before using a DAST tool are:
    • Support for API testing
    • Authenticated scans
    • DevSecOps (ability to run completely automated as part of CI/CD pipelines)

IAST (Interactive Application Security Testing)

  • IASY is a hybrid testing approach that combines the SAST and DAST benefits. Analyzes vulnerabilities by instrumenting the application with agents and sensors in run time, and will have visibility to the entire code base and can point to the exact vulnerable location of the code, unlike DAST. Also, it has the ability to catch runtime issues like misconfigurations, unlike SAST, and has a minimal false-positive rate.
  • Some of the tools that offer IAST are Veracode and Netsparker. 
  • Commonly used evaluation criteria before using an IAST tool are: 
    • Supported technologies
    • Ease of reporting and level of details in the analysis
    • Speed of execution
    • Accuracy of the results with minimal/no false positives

Database Security Scanning

  • A process that identifies vulnerabilities in database applications by examining both internal and external configuration of databases like authentication, confidentiality, integrity, and availability
  • Some of the tools are Scuba, Zenmap, and SQLRecon.

Tools

WhiteSource Scan

WhiteSource has SAST & SCA capabilities to perform security scanning of the code.  SAST capability can be used to detect vulnerabilities in the source code, and SCA can be used to detect vulnerabilities in the open-source dependencies. WhiteSource helps developers to fix the vulnerabilities. It integrates with Jenkins, Bamboo, Azure DevOps, GIT, and TFS.

SonarQube

SonarQube is an open-source platform that inspects the code quality and integrates with GitHub, BitBucket, GitLab, Maven, Gradle, Travis, Jenkins, Bamboo, and Azure DevOps. SonarQube can measure key metrics including bugs, code smells, security vulnerabilities, and duplicated code. SonarQube supports creating SonarQube plugins, which helps in custom code rules.  

IBM CRA

Code Risk Analyzer takes all your Git-based code, configurations, and deployment artifacts, builds a dependency graph, and runs a pipeline of regulatory compliance control checks.  It generates a Bill of Materials (BOM) file that lists dependencies on all third-party OS packages and application packages. It discovers vulnerabilities in packages that are listed in the BOM file. Code Risk Analyzer supports only github.com repos, Git Repos, and Issue Tracking repos that are hosted by IBM Cloud® Continuous Delivery.  CRA can be enabled to scan pull requests and merge.

HCL AppScan

A comprehensive, cloud-based application security solution that integrates with build environments, DevOps tools, and IDEs.  AppScan on Cloud offers a full suite of testing technologies (SAST, DAST, IAST, and Open Source) to provide the broadest coverage. False positives can be set using the AppScan UI.

Gosec

Gosec is a security tool that performs a static code analysis for Golang projects for security flaws. Gosec works by loading up all your source code into an AST (Abstract Syntax Tree) and applies a set of built-in rules looking for common mistakes such as secrets in code.  Allows false positives to be identified with //#nosec G101 G102 (this is a false positive).

OWASP ZAP

Zed Attack Proxy (ZAP) is a free, open-source dynamic scanning tool being maintained under the umbrella of the Open Web Application Security Project (OWASP). ZAP is designed specifically for pen testing of web applications. Set Alert Filters to set the false positives.

Tools Comparison

Tool NamePurposeSupported LanguageIgnore listPros Cons
WhiteSource ScanningOpen Source library scanning tool.   Vulnerabilities are verified by MITRE and NVDJava, C#, C++, Golang, Node.js, Ruby,   .Net, Dockerfiles, Javascript and moreWhitesource.config file to contain the ignore list

Details are clear on the vulnerability impact

Can be used for license type categorization for all the dependencies

Integrates with Eclipse, VsCode, IntelliJ, etc.,

Issues are auto closed once fixed in the repository

Image scanning (OS package) & source code scanning is excluded.
HCL ASOCSource code static scan & dynamic scan tool.  
Uses whitesource software vulnerability database
Android, Kotlin, Java, c/c++, Golang, Groovy, JS, Python, PHP, Scala, Ruby, TypeScript and moreMark the false positives in the UI

One tool to cover static code & dynamic code scanning

Dockerfile issues are scanned

Too many false positives

The false-positive setting works on line numbers so every time the line number changes false positive has to be set again

Focuses mostly on SQL Injection & CSRF related vulnerabilities

Not an extensive source code scan

IBM CRADependency Scanning.
Not a source code scan.
Uses security.snyk.io as the CVE database
Java, Node.js, Python, Golang, Docker files, Kubernetes, Terraform.cra/.fileignore (Can exclude dev dependencies (–excludedev))

Performs base image (OS package) scan

Can be integrated into the pipeline

Auto-created issues don’t have many details (Pipeline has details but it’s not linked to issues)

Issues once fixed are not auto closed

Duplicates are possible as the pipelines are run

If your Dockerfile requires ARG to be passed, make sure that the ARG is set as an environment variable. You can also use the DOCKERBUILDFLAG environment variable.

Supports only github.com repos, Git Repos, and Issue Tracking repos that are hosted by IBM Cloud® Continuous Delivery.

OWASP ZAPOpen-source penetration testing toolJava, Python, Node JS, .NET, PHP or GoFalse positives can be set in the UI.   Ignore alerts using configuration files.

Stable solution for pen-testing / dynamic scan

Automatic updates and pull requests analysis

Available with four different modes of scanning

  • Safe
  • Protected
  • Standard
  • Attack

Better reporting format required

Active scanning is dangerous and depending on your app may create/modify/delete data.

SonarQubeSource code quality and security scanning tool. Vulnerabilities are verified by MITRE and NVDJava (including Android), C#, C, C++, JavaScript, TypeScript, Python, Go, Swift, COBOL, Apex, PHP, Kotlin, Ruby, Scala, and more//No Sonar can be used to exclude a line in the code from scanning

Extensive source code scanning for languages like Java, C, C++, etc.,

Used to detect in code

  • Bugs
  • Code smells
  • Security vulnerabilities
  • Duplicated code

Provides details on how the code can be fixed

Track project security against the OWASP Top 10 and CWE Top 25 standards.

The commercial edition does not support GitHub integration

Enterprise edition is costly

Does not scan dependencies. This needs plugin integration into SonarQube

Defining policies/rules is a challenge

Test coverage reporting needs third party coverage tool integration

GosecCode analysis tool for GoLang.   Vulnerabilities are verified by NVDGoLang//#nosec G101

You can customize gosec to exclude or include certain tests

gosec -track-suppressions can be used to review all suppressions

gosec will fetch automatically the dependencies of the code which is being analyzed when go module is turned on

Multiple output formats supported like text, json, yaml, csv, sonarqube, JUnit XML, html and golint

Every issue is reported with mapping CWE and not CVE

Conclusion

Though Alice had no prior experience with the operation of security scanning tools, she certainly wanted to avoid trying out each tool as they bring in the overhead of rudimentary integration issues with their prototyped new software application environment. 

The selection of security scanning tools is an important decision the team has to make. The findings will further lead to key decisions, such as either blocking delivery of the code in the event of a security scan failure, or documenting a traceable process that can be audited to confirm security acceptance of the tests (i.e., to accept or ignore false positives) in case of dynamic code scans.

Skimming through these comparison details, Alice is now elated. She presents it to Bob; they were able to shortlist in no time.

For Bob, it was clear that avoiding flaky scanning tools is more important than finding the best. Both were gleeful, the overall exercise took less time, and now they can focus on their actual business requirements.



Source link

Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Article

Study: EV owners use automaker smartphone apps often but aren't so happy with them

Next Article

Mom Finds Boyfriend Naked In Bed With 7-Year-Old, Plows Him With Car When He Ran

Related Posts