Full Report
Git, repositories and pipelines…oh my! We unpack standard practices in the web app development process and provide guidance on how to use Tenable Web Application Scanning to secure your code.Awesome! This should be easy. All you need to start is … Wait… what's a pipeline?Well, let's start there. Have you ever used a code repository to track code changes? Every time you make an update to the repository files/code, you have to do what's called a “git commit” and “git push.” Developers use Git as a foundation to run their CI/CD pipelines.Wait … what's Git, and what does CI/CD mean?To be clear, continuous integration and continuous deployment (CI/CD) is a methodology — not a tool.The “D” in CI/CD is often referred to as “delivery” instead of deployment. For the purposes of this blog post, since we are talking about the deployment side of it, I will use that here.Before we get there, let’s talk about version control. Time to roll back a few years. In 2005, Linus Torvalds, the creator of Linux, built something called “Git,” an open source version control software. Version control allows you to track and control all changes to a codebase.These codebases, called repositories, are generally used for managing code that is the basis for any software or website that you can think of. Git is the most commonly used version control system while GitHub, now owned by Microsoft, is one of the cloud-based repository hosting platforms utilizing Git.Developers have been using this great version control tool ever since, but every time they wanted to test their production applications/software, they had to do the following:Log on to a serverPull code from a repositoryPackage code up in a nice zip-type fileSend that package to another server that was the staging/testing environmentRun the application and confirm it still runs at allRun any tests needed against it, such as allowing other developers to come in and poke at it to find broken parts of the applicationThe most efficient developers would make scripts to automate some or all of this work, but there was an even better way… Source: Tenable, December 2024 What is continuous integration?Integration here might not mean what it sounds like. It means that you are building your application and running tests on a schedule or every single time you make a change to your code. Think about how much time this can save. Instead of having to assign tasks out to a team of testers, those tests run every time you change the code. Can you imagine knowing about all of your issues right away?On top of that, continuous integration automatically builds your application, so you don’t have to package and run it yourself, letting you keep working on building.For security pros, this is the spot in a pipeline where the dynamic application security testing (DAST) scanner — available in Tenable Web Application Scanning — can help.At Tenable, we want developers to know about security issues as soon as possible. For reference, this is where software composition analysis (SCA) and static application security testing (SAST) scanning also live. Those tools are used for looking at source code, whereas Tenable Web Application Scanning looks at a built application and scans it with real network requests.Jenkins is considered the first main and widely adopted CI tool. Jenkins helped teams adopt this methodology. Some teams were already doing this with homegrown solutions. We have documentation on how to deploy the web app scanner in a Jenkins CI/CD pipeline.What is continuous deployment?Deployment is when you take what you have built and push it out for real use. It’s building an application for production use rather than just for quick testing. Back in the day, developers would log onto their servers and make updates to the applications on the fly. If something broke, well, you’d better remember the changes you made and have fun spinning that back up.Automated deployment allowed developers to run one script that would spin up an entire environment or application all in one go. Application falls down? No problem! Run the deployment and it can be back up soon.Continuous deployment allows for changes to be made in the source code and for those to be automatically sent to production. No dev or IT team time is wasted in changing live servers.Wrapping it all upPHEW. Ok. A CI/CD pipeline is where you combine version control (Git), continuous integration and continuous deployment. It allows teams to develop applications very quickly and not waste time. The pipeline is the ongoing stream of tests and automated actions that all happens based on code changes.Over time, tools became better and more appeared, such as Bamboo and CircleCI and some others. GitHub Actions came out in 2015, allowing developers to automate software development workflows from within GitHub.Tenable Web Application Scanning can scan any pipeline. It offers code examples for testing for various tools, but you can throw a test into any pipeline.For more documentation on how to implement, see Tenable’s DocumentationNow, back to the original question: So, you want to scan some web apps in the pipeline?You can walk through the “how to run Web App Scans in your CI/CD pipeline” in this public demo: https://demo.tenable.com/share/lajsp7ujjmzbLearn moreView the on-demand webinar Tenable Web Application Scanning Customer Update, April 2024Visit the product page, https://www.tenable.com/products/web-app-scanningDownload the data sheet, Vulnerability Exposure: A simple, scalable approach to dynamic application security testing
Analysis Summary
# Best Practices: Integrating Web Application Scanning into CI/CD Pipelines
## Overview
These practices focus on integrating comprehensive Web Application Scanning (WAS) directly into the Continuous Integration/Continuous Deployment (CI/CD) pipeline workflow. The goal is to automate security testing earlier in the Software Development Life Cycle (SDLC) to identify and remediate vulnerabilities before deployment, ensuring secure application delivery.
## Key Recommendations
### Immediate Actions
1. **Integrate Basic Static Analysis Security Testing (SAST) into Commit/Build Phase:** Ensure basic, fast SAST tools run immediately upon code commit or during the initial build phase to catch low-hanging fruit common coding errors quickly.
2. **Establish "Stop the Build" Criteria for Critical Vulnerabilities:** Configure the pipeline to automatically fail the build process if high or critical severity vulnerabilities are detected by any integrated scanning tool (SAST, DAST, or SCA).
### Short-term Improvements (1-3 months)
1. **Implement Dynamic Application Security Testing (DAST) Prior to Staging/QA:** Integrate DAST scanning (such as Tenable Web App Scanning) to run against the fully deployed application in a non-production or integration environment *before* it reaches the final QA or Staging gate.
2. **Utilize Incremental Scanning for Faster Feedback:** Configure DAST scans to focus only on new or modified code paths/endpoints instead of leveraging full deep scans on every iteration, significantly reducing pipeline runtime.
3. **Integrate Software Composition Analysis (SCA):** Add SCA tools to check all third-party libraries and dependencies for known vulnerabilities upon artifact creation.
### Long-term Strategy (3+ months)
1. **Develop Risk-Based Scanning Tiers:** Implement a tiered scanning strategy where high-risk components (e.g., applications handling sensitive data, public-facing APIs) automatically trigger full, in-depth DAST scans, while lower-risk internal apps run faster, targeted scans.
2. **Establish Unified Exposure Management:** Integrate results from all pipeline scans (SAST, SCA, DAST) into a central platform (like Tenable One Exposure Management Platform) to gain a unified view of application risk across the entire SDLC and runtime environments.
3. **Automate Security Exception Workflows:** Create a standardized, auditable process within the pipeline for developers to request and gain approval for exceptions related to unavoidable, context-specific findings, ensuring no vulnerability bypasses review.
## Implementation Guidance
### For Small Organizations
- **Focus on open-source SCA & basic SAST:** Start by implementing free or low-cost open-source SCA tools (to check dependencies) alongside a fast SAST trial to integrate into the existing build process (e.g., Jenkins freestyle jobs or GitHub Actions).
- **Manual DAST Gate:** Initially, treat the deployment to a staging environment as a manual security gate where a designated person triggers a vulnerability scan using a tool like Nessus/WAS and reviews the report before approving production deployment.
### For Medium Organizations
- **Dedicated Scanning Stage:** Create a formal, mandated "Security Verification Stage" in orchestration tools (e.g., GitLab CI, Azure DevOps Pipelines) between build completion and stage promotion.
- **Automated Reporting and Ticketing:** Configure scanners to automatically generate scan reports and create corresponding tickets (e.g., in Jira) for identified critical and high vulnerabilities, assigning them directly to the responsible development team.
### For Large Enterprises
- **Centralized Policy Enforcement:** Utilize centralized tools capable of aggregating results from diverse pipeline environments (e.g., cloud-native vs. on-premises systems) to enforce standardized security policies across all development teams.
- **Attack Path Analysis Integration:** Leverage advanced platforms that can correlate environment scan findings (DAST/runtime) with pipeline findings (SAST/SCA) to prioritize fixes based on exploitability within the active attack surface.
- **Implement Secrets Scanning:** Integrate comprehensive secrets scanning into the pre-commit or build step to ensure no credentials or keys are accidentally checked into the source code repository or build artifacts.
## Configuration Examples
*Specific tooling configurations were not detailed in the source material, but the general concept is to use native pipeline integration methods:*
| Scanning Type | Integration Point | Configuration Goal |
| :--- | :--- | :--- |
| **SCA** | Pre-Build/Compile Step | Fail if licensing violations or vulnerabilities above a certain CVSS score are found in third-party libraries. |
| **SAST** | Post-Build/Unit Test Phase | Report findings via JUnit/SARIF format compatible with the CI tool, allowing pipeline stage reporting aggregation. |
| **DAST** | Deployment to Integrated Env | Use API tokens within the CI/CD secrets manager to allow the scanner tool to authenticate and test the running application. Configure the scanner to run against defined test URLs/endpoints only. |
## Compliance Alignment
* While the text does not explicitly cite standards, integrating security into the SDLC aligns with:*
- **NIST SP 800-53 (SA/RA/SC Controls):** Emphasis on System and Services Acquisition (SA) for secure development and Risk Assessment (RA) through continuous testing.
- **ISO/IEC 27034 (Application Security):** Provides a framework for security in the application lifecycle management process.
- **CIS Critical Security Controls (Control 16):** Software, Data, Assets, and Services Acquisition, emphasizing vulnerability management throughout development.
## Common Pitfalls to Avoid
- **Scanning Too Late:** Waiting until production deployment or post-deployment monitoring to run significant application scans; this dramatically increases remediation costs and delays releases.
- **Ignoring False Positives:** Allowing the pipeline gate to be bypassed without a formal review process based on accepted false positives, leading to overlooked real vulnerabilities.
- **Not Handling Authentication:** Configuring DAST scans without proper, isolated, and temporary authentication credentials, leading to incomplete or insecure testing coverage.
- **Over-reliance on SAST Alone:** Assuming static analysis covers all application vulnerabilities; DAST is crucial for testing runtime behavior, configuration errors, and complex authentication flows.
## Resources
- **Tenable Web App Scanning (WAS):** Tool used for Dynamic Application Security Testing (DAST) within the pipeline.
- **Tenable One Exposure Management Platform:** Recommended platform for aggregating and managing security risk metrics discovered across the SDLC and runtime.
- **SLCGP Requirements:** Organizations should review these requirements to ensure pipeline automation fulfills mandates around secure application deployment.