Chapter 2 - Security Checks in CD/CD

The Importance of Security Checks in Each Stage of The Pipeline

A key component of DevSecOps is the introduction of a secure CI/CD pipeline. As you read in previous chapters, CI/CD is critical to DevSecOps because it:

  • Automates and embeds security checks early in the development process
  • Ensures rapid feedback regarding potential vulnerabilities
  • Facilitates a proactive approach to security throughout the lifecycle of the application.

Every organization has a different way of defining their pipeline and the stages involved. Regardless of how many stages there are, it is crucial to ensure every stage has security checks from all realms of IT involved. These stages can generally look like:

  • The Planning phase: The first step is to develop a product roadmap (threat modeling), which will help identify potential security threats. In threat modeling, potential vulnerabilities are identified and countermeasures are set in place to mitigate those risks.

  • Coding: As developers begin writing code, take measures to make sure that the code is written in accordance with predefined standards and design guidelines. Use source code scanners to detect pieces of code that might be vulnerable to security threats.

  • Building: As developers begin committing their source code to a shared repository, they need to make sure that automated tests are triggered to verify that the builds comply with requirements.

  • Testing: Once a build is successful, test the software for bugs. If new features are added on, more automated testing is performed.

The stages of SDLC can also be referred as the 6 stages:

  1. Project Planning
  2. Gathering Code Requirements & Analysis
  3. Design and Build
  4. Testing
  5. Release
  6. Deployment/Maintenance

CI/CD Pipeline

Source: Qentelli

Due to the nature of continuous integration, every change needs to be monitored and made sure that it’s safe to release. For every stage, there are multiple different controls that can be embedded to the process, whereas tool integrations are not sufficient by themselves for a secure CI/CD pipeline. Tools must be implemented to support the process mentioned above, but it’s important to understand which tools to use and when. Understanding SAST testing vs. DAST testing espscially during the build stages will help ensure a secure SDLC.

SAST vs. DAST

Category SAST DAST
Purpose SAST involves analyzing source code, byte code, or binary code of an application without executing it. Its purpose is to detect security vulnerabilities early in the development process by identifying parts of the code that might lead to security breaches. DAST involves testing an application’s security by simulating attacks on a running application. It aims to identify vulnerabilities that could be exploited during runtime, such as issues related to user authentication, SQL injection, and cross-site scripting (XSS).
Timeline
  • SAST is typically conducted at the very early stages of the development cycle, often integrated into the Integrated Development Environment (IDE) or Continuous Integration/Continuous Deployment (CI/CD) pipeline.
  • It is done before the application is run, usually as soon as the code is written.
  • Conducted later in the development cycle, often after the application is in a stable build and deployed in a testing environment.
  • It is performed on the running application in a safe envrionment, mimicking real-world hacking techniques.
Pros
  • Can detect vulnerabilities early in the development cycle, reducing the cost and effort of fixing them later
  • If you can prevent vulnerabilities in software before you launch, you'll have stronger code and a more reliable application
  • SAST can show you exactly where to find issues in the code
  • Can be automated and integrated into the development process, facilitating early and regular security checks
  • Can identify runtime and environmental issues that SAST cannot detect
  • Does not require access to source code, making it applicable to any application
  • Offers a real-world perspective on how an attacker might exploit vulnerabilities in a live application
Cons
  • Might produce false positives, requiring additional time for developers to sort through and validate issues
  • Only identifies potential security issues in the static code, without considering runtime behavior or external interactions
  • Requires access to the application's source code, which might not always be possible for third-party actors
  • Heavy reliance on experts to write tests, making it difficult to scale
  • Might miss certain types of vulnerabilities that can only be detected by analyzing the source code.
  • Can lead to false negatives, as some vulnerabilities might not be detectable during a dynamic scan or might depend on specific conditions to trigger.

Comparison and Integration

Integrating both SAST and DAST in the security testing process provides a more comprehensive approach to application security. SAST can identify vulnerabilities early in the code, while DAST can test the application’s behavior in a runtime environment, catching issues that static analysis might miss. Together, they offer a balanced and thorough method for securing applications throughout the development lifecycle.

Vulnerability scanning

Vulnerability scanning in a CI/CD pipeline refers to the automated process of identifying security weaknesses in the software code, dependencies, and runtime environments as part of the continuous integration and delivery process. This scanning can detect issues such as insecure coding practices, outdated libraries, misconfigurations, and other vulnerabilities that could potentially be exploited by attackers. You read above the difference between SAST testing and DAST testing. Those processes can be testing using a variety of tools. Some may be cheaper than others, require contracts with experts, or could just be a web plug in. Some of the most popular options you may hear of are listed below

Examples of widely-used tools in industry

SonarQube - A comprehensive tool that provides static code analysis, identifying vulnerabilities, bugs, and code smells in several programming languages

OWASP ZAP (Zed Attack Proxy) - An open-source dynamic application security testing tool that can identify security vulnerabilities in web applications during development and testing phases

Fortify - Provides static and dynamic application security testing tools to identify vulnerabilities in code and running applications

Veracode - Offers a suite of security tools, including static, dynamic, and interactive application security testing, to identify and fix vulnerabilities at various stages of the software development lifecycle

Snyk - Specializes in identifying and fixing vulnerabilities in open-source dependencies and container images, integrating seamlessly with CI/CD pipelines

GitLab CI/CD Security Scanning - Offers built-in security scanning features in its CI/CD pipelines, including static and dynamic analysis, dependency scanning, and container scanning

Jenkins with security plugins - Jenkins, a popular automation server, can be configured with various security plugins to perform static and dynamic analysis, as well as other security checks within the CI/CD pipeline

There are countless variations of vulnerability scanners out there and are constantly being innovated. Every software team should take throrough time to research and test as many tools as possible within their budget and timeline to ensure their pipeline is fully covered.

References

1. “What is CI/CD security?” Red Hat, Link. Accessed 9 Apr. 2024.

2. “Security in every stage of CI/CD pipeline” AWS, Link. Accessed 9 Apr. 2024.

3. “SAST, DAST, and IAST Security Testing” Contrast Security, Link. Accessed 9 Apr. 2024.

4. “How to use the Jenkins Security Scan “ Jenkins, Link. Accessed 9 Apr. 2024.

5. “SonarQube” SonarQube, Link. Accessed 9 Apr. 2024.

6. “Snyk Open Source” Snyk, Link. Accessed 9 Apr. 2024.

7. “Vulnerability Scanner Tools” Veracode, Link. Accessed 9 Apr. 2024.

8. “What is Fortify and How it works? An Overview and Its Use Cases” DevOps School, Link. Accessed 9 Apr. 2024.