DevSecOps Pipeline Language Exercises

SAST (Static Application Security Testing) analyses source code, bytecode, or binaries without executing the application — it scans the code itself. DAST (Dynamic Application Security Testing) attacks a running application from the outside, simulating how an attacker would probe it. You might say: "We run SAST in the build stage to catch injection vulnerabilities early, and DAST against our staging environment to find runtime issues like broken authentication." SAST finds issues earlier and cheaper; DAST finds runtime vulnerabilities that only appear when the application is running.

Shift left security means moving security testing and controls earlier in the software development lifecycle — toward the "left" of the development pipeline (design and coding) rather than leaving security to the end (testing or deployment). The phrase comes from the idea that a typical pipeline is read left to right. Shift left practices include: developer security training, IDE security linting plugins, pre-commit hooks that scan for secrets, SAST in pull request checks, and threat modelling during design. The business case is that vulnerabilities found earlier are exponentially cheaper to fix.

A security gate is a mandatory checkpoint in a CI/CD pipeline that blocks deployment if security criteria are not met. For example: "Our pipeline has a security gate after the SAST scan — if any critical-severity findings are detected, the build fails and the merge is blocked until they are resolved." Security gates enforce a minimum security bar and prevent vulnerabilities from being promoted to production. Teams negotiate gate thresholds (e.g., "fail on Critical and High, warn on Medium") to balance security with development velocity.

Secret scanning detects credentials, API keys, tokens, and passwords accidentally committed to a code repository. These findings are treated as critical because exposed secrets can be exploited immediately. Common secret scanning tools include: GitHub's built-in secret scanning, GitLeaks, TruffleHog, and Detect-Secrets. In a pipeline context: "We have secret scanning configured as a pre-receive hook — any push containing a pattern that matches a known secret format is blocked before it reaches the remote repository." Rotation (changing the secret immediately after exposure) is the required remediation.

Compliance as code means expressing regulatory and policy requirements as machine-readable rules that are automatically enforced in CI/CD pipelines — rather than relying on manual audits. Tools include: Open Policy Agent (OPA), HashiCorp Sentinel, and AWS Config rules. You might say: "We've codified our SOC 2 controls in OPA policies. Every Terraform plan is evaluated against these policies before apply — infrastructure that violates a control is automatically blocked." This approach makes compliance auditable, repeatable, and faster than manual checklist-based compliance.

Container image scanning analyses Docker images for known vulnerabilities (CVEs) in the operating system packages and application dependencies before the image is deployed. Key vocabulary: CVE (Common Vulnerabilities and Exposures — the standard identifier for known vulnerabilities), base image (the parent image a container is built from), image registry (where images are stored, e.g., Docker Hub, ECR, GCR), and vulnerability severity (Critical, High, Medium, Low). Tools include: Trivy, Clair, Anchore, and Snyk Container. Standard pipeline language: "We scan all images on push to the registry and block deployment if Critical CVEs are present."

A vulnerability remediation SLA defines the maximum time allowed to fix a vulnerability after it is discovered, based on its severity. A typical SLA looks like: Critical — 24 hours; High — 7 days; Medium — 30 days; Low — 90 days. In a security review: "This finding is classified as High severity, which means our SLA requires remediation within 7 days. I've created a ticket and assigned it to the team." SLAs create accountability and are often required by compliance frameworks like PCI DSS and SOC 2.

SCA (Software Composition Analysis) scans a project's third-party dependencies — libraries and packages — for known vulnerabilities and licence risks. SAST analyses your own source code for security flaws. SCA answers "are any of the open-source libraries we use vulnerable?"; SAST answers "does our own code have security bugs?" Both are used together in DevSecOps pipelines. Tools: Dependabot, OWASP Dependency-Check, Snyk Open Source, Mend (formerly WhiteSource). In a standup: "SCA flagged a critical CVE in our logging library — we need to upgrade to the patched version today."

A supply chain attack targets the software dependencies or build infrastructure of an application rather than the application itself — for example, injecting malicious code into a widely-used open-source library. DevSecOps countermeasures include: pinning dependency versions (using exact version hashes rather than floating ranges), using private package mirrors, generating and verifying SBOMs (Software Bill of Materials), signing container images, and using SLSA (Supply chain Levels for Software Artefacts) provenance attestations. This vocabulary is increasingly required in enterprise security conversations.

Security posture is the overall security status of an organisation's software systems and infrastructure — a holistic assessment of how well-protected it is against threats. It is assessed using metrics like: mean time to detect (MTTD) vulnerabilities, mean time to remediate (MTTR), percentage of pipeline runs passing all security gates, open critical CVE count, and secrets exposure incidents. In an executive update you might say: "Our security posture has improved significantly this quarter — our open critical vulnerabilities are down 60% and all new deployments now pass our security gate checks."