This article is based on a contribution by Meera Rao, senior principal consultant at Synopsys, originally published on computerweekly.com (November 2019). Synopsys is known for its work in silicon chip design, verification, IP integration, and application security testing.
Security in CI/CD: The Core Challenge
CI/CD pipelines are built around three principles: speed, repetition, and automation. Security, by contrast, has traditionally been a gate at the end of the development process—a final checkpoint before release. These two approaches are fundamentally in tension, and that tension is what “shifting security left” is designed to resolve.
Embedding security into CI/CD does not mean slowing the pipeline down. It means choosing the right tools for each stage, automating what can reasonably be automated, and knowing when human judgment is irreplaceable.
Application Security Testing Tool Categories
Before designing a secure pipeline, teams need to understand the distinct tool categories available and what each one can—and cannot—do.
Static Application Security Testing (SAST)
SAST tools analyse source code, bytecode, or binaries without executing the application. They operate in two modes:
- Lightweight IDE plugins — Flag common vulnerability patterns in real time as developers write code, offering immediate remediation guidance. These are low-friction and integrate directly into developer workflows.
- Deep-scan engines — Perform full path coverage analysis, consider business logic, and ensure every code path and potential execution branch is tested. These are better suited to pipeline stages such as nightly builds or pre-merge checks.
SAST is most effective early in the development cycle, where the cost of fixing a vulnerability is lowest.
Software Composition Analysis (SCA)
Modern applications are composed largely of open source libraries and third-party components. SCA tools provide visibility into the full software supply chain by analysing these dependencies and their associated known vulnerabilities.
SCA outputs typically include a software bill of materials (SBOM), a list of known CVEs affecting your dependencies, and licence risk information. Given the volume of open source consumption in most organisations, SCA is no longer optional—it is a baseline requirement.
Fuzz Testing
Fuzz testing (fuzzing) simulates real-world attack patterns by automatically bombarding an application with malformed, unexpected, or random inputs. Unlike SAST, which analyses code structure, fuzzing discovers vulnerabilities by observing runtime behaviour under adversarial conditions.
Fuzzing is particularly effective at uncovering misuse cases—failure modes that developers did not anticipate and that are therefore not covered by standard unit or integration tests. It surfaces hidden vulnerabilities such as buffer overflows, null pointer dereferences, and input-handling errors.
Dynamic Application Security Testing (DAST)
DAST tools test a running application from the outside, mimicking penetration testing techniques. Because the application is executing, DAST can detect runtime vulnerabilities—such as authentication flaws, injection points, and server misconfiguration—that static analysis cannot see.
DAST is typically applied later in the pipeline, against a staging or pre-production environment, because it requires a deployed and running application target.
Interactive Application Security Testing (IAST)
IAST is a newer category that instruments the application itself—typically via an agent—and monitors it from within during runtime testing. This approach combines some of the code-level precision of SAST with the runtime context of DAST, and is designed to reduce the false-positive rates that trouble both techniques when used independently.
IAST works well alongside automated functional testing: as your test suite exercises the application, the IAST agent records security observations in parallel, requiring no separate test execution phase.
Best Practices for Integrating Security Into CI/CD
1. Treat Security Bugs the Same as Functional Bugs
A mature engineering organisation applies consistent standards to all defects. A critical security vulnerability should carry the same weight as a critical functional defect—it blocks the build and gets prioritised for remediation. Allowing security issues to accumulate in a backlog while functional issues are resolved creates technical debt that compounds into business risk.
Practically, this means configuring your pipeline to fail the build when security findings exceed a defined severity threshold—for example, failing on any finding rated medium or above. The development team is notified immediately, the same way they would be notified of a failed unit test.
2. Build Continuous Collaboration, Not Just Continuous Testing
Shifting security left is not solely a tooling problem—it is an organisational problem. Development, security, and operations teams need shared ownership of security outcomes. Business stakeholders also have a role: security requirements must be treated as first-class requirements alongside functionality and performance.
Organisations that focus only on acquiring tools without addressing the collaboration gaps between teams will find that their security posture improves only marginally. Shared dashboards, shared on-call responsibilities, and joint threat modelling sessions are as important as the toolchain itself.
3. Choose Automation Tools Deliberately
Automation is essential at CI/CD velocity, but selecting and configuring security tools is a skilled discipline. Key considerations include:
- Language and framework support — Different languages require different tooling. Even within a single language, different versions or frameworks may require different rule sets or configurations.
- Customisation — Applying a tool’s default rule set to an application without tailoring it to your architecture is a common source of noise (false positives) and blind spots (false negatives).
- Integration effort — No security tool is truly plug-and-play. Budget time for integration, tuning, and ongoing maintenance as your codebase evolves.
4. Know What Automation Cannot Do
Automated security tools are necessary but not sufficient. Specific limitations to keep in mind:
- Tools cannot interpret their own results. A finding flagged by a SAST tool may be a true positive, a false positive, or context-dependent. A security engineer must triage results and make that determination.
- Tools cannot certify that software is secure. A clean scan report means the tool found nothing within its detection capability—not that the application is free of vulnerabilities.
- Tools cannot discover novel attack classes. Automated tools are pattern-based. New vulnerability classes or application-specific business logic flaws require manual review, threat modelling, and penetration testing by experienced practitioners.
- Automation does not eliminate manual testing. Automated and manual testing are complementary. Define clearly which scenarios require human review and build that into your process.
Common Mistakes to Avoid
Treating Security Tooling as a One-Size-Fits-All Solution
Enterprise applications are heterogeneous. A single application may use multiple languages, multiple frameworks, and a mix of in-house code and third-party components. No single tool covers all of these effectively. A realistic security toolchain for a modern application will combine several complementary tools, each tuned to its specific domain.
Applying Default Tool Configurations Without Customisation
Using a tool’s out-of-the-box rule set against a complex enterprise application typically produces excessive noise—high false-positive rates that erode developer trust in the tool. When developers learn to ignore scanner output because it is usually irrelevant, the tool stops providing value. Invest in rule tuning and suppression lists early.
Skipping the Build-Failure Gate
A security scan that runs but never fails the build is a reporting tool, not a control. If findings can be ignored without consequence, they will be. Defining and enforcing a severity-based build-failure policy is the mechanism that gives security testing real teeth in the pipeline.
Putting It Together: A Layered Security Pipeline
A practical approach maps tool categories to pipeline stages based on when each tool provides the most value and the least friction:
| Pipeline Stage | Recommended Tool Types |
|---|---|
| Developer workstation / IDE | Lightweight SAST plugins, SCA dependency checks |
| Pull request / pre-merge | SAST (fast scan), SCA |
| CI build | Full SAST scan, SCA, fuzz testing (where applicable) |
| Staging / pre-production | DAST, IAST (alongside functional test suite) |
| Periodic / release gate | Manual penetration testing, threat modelling review |
The goal is not to run every tool at every stage—that would create unacceptable latency. It is to ensure that the right checks happen at the right point in the delivery process, with fast feedback for developers and deeper validation before code reaches production.
Summary
Security in CI/CD is not a single tool or a single decision—it is an ongoing engineering discipline. The most effective organisations apply a layered approach: lightweight, fast checks close to the developer; deeper automated analysis in the pipeline; and human expertise for triage, manual testing, and architectural review. They enforce security quality gates with the same rigour they apply to functional quality, and they invest in cross-team collaboration as much as they invest in tooling.
The tooling landscape will continue to evolve, but these principles—breadth of coverage, appropriate automation, and meaningful human oversight—will remain the foundation of a secure software delivery process.