Practical Application Security Testing in CI Pipelines [PART ONE]

‘Shifting security left’ has become an important characteristic in modern software development. This allows for application security testing to be performed in the early stages of the development lifecycle, ensuring that security vulnerabilities are detected early before an application hits the production environment.

Four main stages of application security testing in CI/CD are Software Composition Analysis (SCA), Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Interactive Application Security Testing(IAST).

• Software Composition Analysis (SCA) provides information about open-source software components, license information, and their vulnerabilities.
• Static Application Security Testing (SAST) performs analysis on an application’s source code to identify vulnerable patterns.
• Dynamic Application Security Testing (DAST) performs black-box testing/vulnerability analysis on a running application.
• Interactive Application Security Testing (IAST) combines both static and dynamic testing approaches to properly identify software application vulnerabilities and reduce false positives. It matches a vulnerability with the underlying area in the application’s source code.

To get the best value when implementing security testing, the following points should be taken into consideration:

1. Static analysis coverage – When performing static application security testing, code coverage is an important factor. Code coverage in this sense refers to the amount of application or deployment-related files being assessed for security flaws. This will typically include source code files as well as deployment files such as Kubernetes manifests, Dockerfiles, Ansible playbooks etc. Secrets detection is also a good practice to have in place during the static analysis stage to identify secrets committed to your repositories and avoid potentially hardcoding keys or exposing them in docker images.
2. Containers – Container images should always be scanned for vulnerabilities. Vulnerabilities can be introduced by base images and software packages or dependencies.
3. Vulnerability Management – Centralized vulnerability management is essential for analysis, alerting, and reporting purposes. With vulnerability management, you gain a historical perspective of the vulnerabilities affecting your application.

Here are some considerations important for introducing security testing in your CI pipelines.

• Accuracy: Security tools should be selected and fine-tuned to reduce false positive detection allowing more focus on detecting and fixing real vulnerabilities that affect your application.
• Real-Time Detection: Vulnerability identification should happen in real-time as the pipeline is in progress. Compliance checks or quality gating should also be in place to identify non-compliance to best practices or security standards.
• Continuity: Security testing should be a continuous process with constant feedback and alerting. An example of this is when software dependencies used in an application have become vulnerable after it has been deployed to production. Assuming that no changes have been made to the running application in months, how will you be able to identify and fix this vulnerability?
• Reliability – Tools should reliably detect security vulnerabilities depending on the context in which it is being applied.

Some important criteria used in selecting a tool may include:

• Language support – Tools with multi-language support should be preferred over single language tools.
• Detection capabilities – Good detection engines will greatly reduce false-positive and false-negative detections.
• Ease of use and integration – Integration with CI pipelines and other security platforms provides centralized vulnerability management.
• Alerting capabilities – Alerting support will aid teams to respond to issues more quickly.
• Cost – Open-source tools may be preferred over commercial solutions in organizations with constrained security budgets.

Common Security Testing Tools

Here are some example security testing tools which will include at least one open-source tool in each category.

Software Composition Analysis

• OWASP Dependency-Check (Open-Source)

OWASP Dependency-Check analyzes software dependencies by generating a report of Common Vulnerabilities and Exposures (CVEs) for each dependency using its Common Platform Enumeration (CPE). It can be used as a command-line tool or integrated directly as a project plugin.

• OWASP Dependency Track (Open-Source)

OWASP Dependency Track is a software supply chain risk analysis tool that uses a Software Bill of Materials (SBOM) for vulnerability detection which offers capabilities that traditional SCA tools cannot provide. It can be deployed on a server or Kubernetes cluster.

• Snyk (Open-Source | Commercial )

Snyk provides useful integrations with IDEs, SCMs for identifying vulnerable software packages. Snyk offers both open-source and commercial options.

Static Application Security Testing

• Sonarqube (Open-Source | Commercial )

Sonarqube offers continuous code inspection with automatic reviews to identify security vulnerabilities as well as bugs, code smells with support for up to 20 programming languages.

• Snyk Code (Commercial)

Snyk code provides efficient and actionable static application security testing with SCM and IDE plugin integrations to identify security vulnerabilities in real-time.

• Veracode Static Analysis (Commercial)

Veracode Static Analysis allows development teams to code securely by offering SDLC and IDE integrations, sandbox environments for testing and fixing code.

• MobSF (Open-Source)

Mobile Security Framework is an open-source all-in-one mobile application security evaluation tool that can carry out dynamic and static analysis. Its API allows for easy integration with CI/CD pipelines.

Dynamic Application Security Testing

• Veracode Dynamic Analysis (Commercial)

Veracode Dynamic Analysis provides a solution that allows automated scanning of web applications to discover weaknesses that can be exploited by a bad actor and tackle the threat immediately. This ability to test thousands of applications concomitantly with faultless outcomes can reduce the risk of exposure

• GitLab DAST (Commercial)

Gitlab DAST which is built on the open-source OWASP ZAP tool makes it possible for GitLab users to configure and implement security testing on their applications within the CI/CD pipeline.

• OWASP ZAP (Open-Source)

Zed Attack Proxy (ZAP) is an open-source application security testing tool. ZAP is developed especially for scanning web applications providing several options for automation and use in CI/CD pipelines.

• Synopsis Managed DAST (Commercial)

Synopsis Managed DAST helps you identify common to critical software security vulnerabilities in your running application by using automated testing tools with limited manual testing.

Some other DAST solutions are:

• Acunetix (Commercial)
• Netsparker (Commercial)

Interactive Application Security Testing

• Contrast Assess (Commercial)

Contrast Assess analyzes code through instrumentation techniques in real-time from within the application. Contrast Assess then uses the intelligence gathered within the application to confirm vulnerabilities in code.

• Synopsis Seeker (Commercial)

Synopsis seeker uses instrumentation techniques to identify and determine the exploitability of vulnerabilities within running applications. It also offers integration into CI/CD workflows.

• Hdiv Detection (Commercial)

Hdiv uses runtime dataflow technique to expose flaws in the source code before they are exploited by reporting the file and line number of the vulnerability

• OpenRASP IAST Scanner by Baidu (Open-Source)

Openrasp-iast is a gray box scanning tool that combines accurate detection of

vulnerabilities with internal hook point information.

Some other IAST solutions are:

• Veracode (Commercial)
• Checkmarx (Commercial)

In the next part of this series, we will look at common implementations and workflows when using some of the tools mentioned above. This will allow you to understand the possibilities in each phase of security testing and decide on the best approach for your organization.

Notes

• https://owasp.org/www-community/Source_Code_Analysis_Tools.
• https://www.linuxfoundation.org/resources/publications/an-open-guide-to-evaluating-software-composition-analysis-tools

‍