CI/CD Security Vocabulary

Secret scanning is the automated detection of sensitive credentials — API keys, tokens, passwords, private keys — that have been accidentally committed into source code, configuration, or git history. Tools use regex patterns and entropy analysis (and provider-specific signatures) to flag likely secrets in commits and pull requests, ideally blocking them before they merge or reach production. Because git history is permanent, a leaked secret must be both rotated and purged. Running secret scanning in CI/CD, plus pre-commit hooks, prevents one of the most common and damaging security mistakes.

SAST (Static Application Security Testing) analyzes source code, bytecode, or binaries without executing them, finding vulnerabilities like injection flaws, hardcoded secrets, and unsafe APIs early in development. DAST (Dynamic Application Security Testing) instead probes a running application from the outside — like an attacker — sending crafted requests to detect issues such as XSS, authentication weaknesses, and misconfigurations that only manifest at runtime. SAST gives broad code coverage and pinpoints exact lines but yields false positives; DAST finds real runtime issues but only on exercised paths. They are complementary and often both run in CI/CD.

Signed commits are git commits (or tags) that carry a cryptographic signature — using GPG, SSH, or S/MIME keys — proving who authored them and that their content has not been altered. Without signing, the author name and email in a commit are trivially spoofable, so anyone could impersonate a maintainer. When verified against trusted public keys, signed commits show as "Verified," letting reviewers and CI enforce that only commits from known contributors are accepted. This protects the supply chain by guaranteeing provenance and integrity of code entering the repository.

An SBOM (Software Bill of Materials) is a formal, machine-readable inventory of every component, library, and dependency — along with versions and licenses — that makes up a piece of software. Standard formats include SPDX and CycloneDX. An SBOM provides transparency into the supply chain, so that when a new vulnerability (like Log4Shell) is disclosed, organizations can instantly determine whether and where they are affected. Generating an SBOM during the build and shipping it alongside releases has become a key practice and, increasingly, a regulatory requirement for software security.

A supply-chain attack compromises software indirectly by targeting something it trusts — a third-party dependency, a build server, a package registry, or an update mechanism — rather than attacking the application directly. Examples include publishing a malicious package version, typosquatting popular package names, or injecting code into a build pipeline (as in the SolarWinds and event-stream incidents). Because the malicious code arrives through trusted channels, it can spread widely before detection. Defenses include dependency pinning, SBOMs, signed artifacts, reproducible builds, and least-privilege CI/CD to verify and limit what enters and runs in the pipeline.