DevSecOps Pipeline

Automated security analysis of source code, bytecode, or binaries without executing the application — identifying vulnerabilities such as SQL injection, XSS, and hard-coded secrets by examining code structure and data flows.

"Our SAST scanner runs on every pull request and blocks merge if it detects high-severity findings — last sprint it caught a SQL injection vulnerability introduced in the search endpoint before the code reached staging."

Security testing that exercises a running application by sending malicious inputs and observing responses — detecting runtime vulnerabilities like authentication flaws, injection points, and misconfigured headers that SAST cannot find in source code alone.

"DAST scanning in our staging environment discovered an exposed admin endpoint that wasn't covered by SAST — the dynamic scanner found it by crawling the application and attempting unauthorised access, revealing a missing authentication check."

Automated analysis of open-source dependencies to identify known vulnerabilities (CVEs), licence compliance issues, and outdated components — generating a software bill of materials (SBOM) for each build.

"SCA scanning flagged that our Node.js application depended on a transitive dependency with a critical CVE — a package three levels deep in the dependency tree. The SCA tool generated a remediation PR upgrading the vulnerable package automatically."

A policy-enforced checkpoint in a CI/CD pipeline that blocks deployment if security scan results exceed defined thresholds — for example, blocking on any critical CVE or more than five high-severity SAST findings.

"We configured security gates that block promotion to production if SAST finds any critical findings, SCA finds any critical CVEs with a CVSS score above 9.0, or container scanning detects a critical OS vulnerability. The gate has blocked 14 deployments in the past quarter, all of which contained legitimate issues."

Automated detection of accidentally committed credentials, API keys, tokens, and private keys in source code repositories — preventing secret exposure before code is pushed or immediately flagging it if already committed.

"Secret scanning caught an AWS access key committed to a feature branch by a developer who had hardcoded it temporarily for testing — the pipeline blocked the push and triggered an automated key rotation workflow before the credential was ever visible in the remote repository."

Analysis of container images for known OS and application-layer vulnerabilities before deployment — scanning the base image, installed packages, and application dependencies against CVE databases.

"Container image scanning in our registry found that the base alpine image used by 23 microservices had three critical CVEs patched in a newer release — we updated the base image in the shared Dockerfile template and all images were rebuilt and rescanned within two hours."

A standardised identifier for publicly known cybersecurity vulnerabilities — each CVE entry includes a unique ID, severity score (CVSS), description, and references to patches or mitigations. CVE identifiers are the universal currency for tracking and communicating vulnerability status.

"Our SCA tool flagged CVE-2021-44228 (Log4Shell) in a dependency — the CVE identifier allowed every team to immediately identify which services were affected, what the CVSS score was (10.0 critical), and which version fixed the issue, coordinating remediation across 40 services in under 24 hours."

A policy that defines the maximum time allowed to fix a detected vulnerability based on its severity — for example: critical within 24 hours, high within 7 days, medium within 30 days, low within 90 days.

"Our remediation SLA requires critical CVEs to be patched within 24 hours of detection — the security dashboard tracks SLA compliance per team, and breaches are escalated automatically to the engineering director. Last quarter we achieved 97% on-time remediation for critical findings."

The practice of integrating security testing and controls earlier in the software development lifecycle — moving security from a final gate before release to an automated check at every code commit, reducing the cost and complexity of fixing vulnerabilities.

"Shifting security left reduced our average time-to-fix for vulnerabilities from 47 days (found in production pen testing) to 3 days (found in PR pipelines) — developers fix issues in the same context they introduced them rather than switching context weeks later."

A policy decision for how a security control behaves when it encounters an error or timeout — fail-open allows the action to proceed (prioritising availability), fail-closed blocks the action (prioritising security). Critical security gates should be fail-closed; non-critical advisory checks may be fail-open.

"We made our SAST gate fail-closed: if the scanner times out or errors, the pipeline blocks rather than proceeding. The licence compliance checker is fail-open because a scanner outage should not block a critical hotfix — the team receives an alert and reviews manually."

An open-source, all-in-one security scanner by Aqua Security that detects vulnerabilities in container images, filesystems, Git repositories, Kubernetes configs, and IaC files — widely adopted in CI/CD pipelines for its speed, breadth, and zero-configuration startup.

"We replaced three separate scanning tools with Trivy in our pipeline — it now scans the container image, the Terraform files, and the Helm chart in a single step, reporting all findings in a unified SARIF output that integrates directly with GitHub Security Advisories."

The practice of expressing compliance requirements and security policies as executable code or configuration files that can be automatically checked in CI/CD pipelines — replacing manual audit checklists with automated, version-controlled policy enforcement.

"We implemented compliance-as-code using Open Policy Agent (OPA) to enforce our CIS benchmark policies — every Kubernetes manifest is validated against 47 policy rules before deployment. The policies live in Git alongside the application code and are reviewed as part of the same PR process."