01 Executive Overview
Continuous integration and continuous delivery (CI/CD) pipelines now hold some of the most privileged access in any technology organization. A single pipeline can read source code, fetch third-party packages, hold cloud credentials, sign release artifacts and push changes straight to production. That concentration of trust makes the pipeline itself a primary target, and attacks on build systems and software supply chains have shown that compromising one pipeline can reach every customer of the software it ships.
This white paper gives engineering, platform and security teams a practical checklist to assess, secure and improve their delivery pipelines. It groups 59 controls into eight domains, defines the evidence that shows each control is in place, and provides a scoring model, a 90-day improvement roadmap and an ownership model so the assessment leads to measurable change.
How to use this checklist
- Scope one pipeline, product or platform at a time; record what is in scope before scoring.
- Score each control from 0 to 3 using the evidence listed, not verbal assurance.
- Calculate category and overall maturity in Section 11 and classify the result.
- Plan remediation with the 90-day roadmap in Section 12 and assign owners using Section 13.
- Reassess at the end of each 90-day cycle and compare scores.
Requirement language
This document is a practical checklist, not a standard, regulation or certification scheme, and scoring well against it does not by itself demonstrate compliance with any external framework. Each control carries one of two tiers:
- Baseline — the minimum expected for any pipeline that builds or deploys software to production. A Baseline control scored 0 or 1 should be treated as a priority finding.
- Advanced — recommended for critical systems, regulated environments and organizations targeting higher supply-chain assurance. Teams should adopt these based on risk.
About the 2027 edition
This edition reflects frameworks and guidance published as of November 2026, including the OWASP Top 10 CI/CD Security Risks, SLSA v1.2, NIST SP 800-218 (SSDF v1.1, with v1.2 in public draft), NIST SP 800-204D and the joint CISA/NSA guidance on defending CI/CD environments. It does not anticipate standards that have not yet been released; where a referenced framework is revised, teams should map controls to the newer version.
02 Understanding the CI/CD Attack Surface
A delivery pipeline is a chain of systems: source control, the CI/CD platform, build runners, package and artifact registries, secrets stores, cloud accounts and the runtime environment. Each link holds credentials or trust that an attacker can reuse. The table below shows the stages this checklist covers and representative controls at each one.
Figure 1. Secure CI/CD pipeline stages and representative controls
| Stage | Representative controls |
|---|---|
| Source | Branch protection · Signed commits · Code owners |
| Build | Ephemeral runners · Pinned deps · Short-lived creds |
| Test & Scan | SAST / SCA · Secrets scan · IaC scan |
| Package & Sign | SBOM · Provenance · Signature |
| Deploy | Policy gate · Approvals · Verify signature |
| Run & Monitor | Audit logs · Alerting · Drift detection |
Identity, secrets and audit controls span every stage.
Common attack paths
- Poisoned pipeline execution — an attacker changes pipeline configuration or build scripts, for example through a pull request, to run their own commands with the pipeline's privileges.
- Credential theft — long-lived tokens and cloud keys stored in CI variables, logs or runner disks are exfiltrated and reused outside the pipeline.
- Dependency and integration abuse — malicious or hijacked packages, dependency confusion, and compromised third-party actions or plugins run inside the build.
- Artifact tampering — artifacts are replaced or modified between build and deployment because nothing verifies their origin or integrity.
- Blind spots — missing audit logs mean an intrusion into the pipeline is detected late or not at all.
Mapping to the OWASP Top 10 CI/CD Security Risks
The domains in this checklist map to the OWASP Top 10 CI/CD Security Risks as follows.
| OWASP ID | Risk | Addressed in |
|---|---|---|
| CICD-SEC-1 | Insufficient Flow Control Mechanisms | Section 3, Section 8 |
| CICD-SEC-2 | Inadequate Identity and Access Management | Section 4 |
| CICD-SEC-3 | Dependency Chain Abuse | Section 6 |
| CICD-SEC-4 | Poisoned Pipeline Execution (PPE) | Section 3, Section 5 |
| CICD-SEC-5 | Insufficient PBAC (Pipeline-Based Access Controls) | Section 4, Section 5 |
| CICD-SEC-6 | Insufficient Credential Hygiene | Section 4 |
| CICD-SEC-7 | Insecure System Configuration | Section 5, Section 8 |
| CICD-SEC-8 | Ungoverned Usage of 3rd Party Services | Section 6 |
| CICD-SEC-9 | Improper Artifact Integrity Validation | Section 7, Section 8 |
| CICD-SEC-10 | Insufficient Logging and Visibility | Section 10 |
03 Governance and Source Control Security
Source control is where every change enters the pipeline. These controls ensure that no single person or compromised account can push unreviewed code or pipeline changes to a branch that builds production artifacts.
Controls: 8 (6 Baseline, 2 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| GOV-01 — Baseline | Branch protection on default and release branches | Direct pushes, force-pushes and branch deletion are blocked; merges require a pull request and passing status checks. | Branch protection or ruleset configuration export |
| GOV-02 — Baseline | Mandatory independent review | At least one approval from someone other than the author; approvals are dismissed when new commits are pushed. | Ruleset settings; sample of recently merged pull requests |
| GOV-03 — Baseline | Code owners for pipeline and infrastructure files | Changes to pipeline definitions, infrastructure as code and deployment manifests require review by designated owners. | CODEOWNERS file; review records on affected changes |
| GOV-04 — Baseline | Pipeline definitions managed as code | Production pipelines are defined in version control; no UI-only job configuration that bypasses review. | Pipeline inventory showing source location for each pipeline |
| GOV-05 — Baseline | Source control organization hardening | SSO and MFA are enforced for all members; default repository permissions are minimal; outside collaborators are reviewed. | Organization settings export; MFA compliance report |
| GOV-06 — Baseline | Repository and pipeline inventory | An up-to-date inventory lists repositories, pipelines, owners and business criticality. | Inventory with last review date |
| GOV-07 — Advanced | Untrusted contributions run without privileges | Builds triggered by forks or external contributors run without secrets and with read-only tokens; privileged triggers are reviewed. | Workflow configuration review; trigger settings |
| GOV-08 — Advanced | Signed commits and tags | Protected branches require verified commit signatures; release tags are signed. | Ruleset requiring signatures; tag verification output |
04 Identity, Access Management and Secrets Security
Pipelines need credentials to reach registries, cloud accounts and production systems. The goal is to replace standing secrets with short-lived, narrowly scoped identities, and to make any secret that must exist hard to leak and fast to revoke.
Controls: 8 (7 Baseline, 1 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| IAM-01 — Baseline | Short-lived credentials through workload identity federation | Pipelines obtain temporary cloud credentials through OIDC federation instead of storing static access keys. | Cloud trust policies; confirmation that no static cloud keys remain in CI variables |
| IAM-02 — Baseline | Least-privilege pipeline identities | Each pipeline and environment uses its own identity with only the permissions it needs; deployment roles cannot broadly modify IAM. | Role and policy documents; latest access review |
| IAM-03 — Baseline | Minimal default job token permissions | Built-in CI job tokens are read-only by default and elevated only for the jobs that require it. | Platform and workflow permission settings |
| IAM-04 — Baseline | Centralized secrets management | Secrets live in a secrets manager or vault, are injected at runtime and are masked in logs; none are committed to source. | Secrets manager configuration; log masking test result |
| IAM-05 — Baseline | Secret scanning with push protection | Repositories and history are scanned for secrets, and push protection blocks new secrets before they land. | Scanner configuration; alert triage records |
| IAM-06 — Baseline | Rotation and revocation process | Credentials have defined rotation periods and a documented, tested procedure for revoking a leaked secret. | Rotation logs; revocation runbook |
| IAM-07 — Baseline | Secured human access to CI/CD platforms | People access CI/CD and registry platforms through SSO with MFA; administrator roles are few and reviewed regularly. | Administrator list; access review record |
| IAM-08 — Advanced | Environment-scoped secrets | Production secrets are available only to jobs that target the production environment after the required approvals. | Environment and secret scoping configuration |
05 Build Agents, Runners and Execution Isolation
Runners execute untrusted code by design: every build runs code and dependencies that changed since the last one. Isolation ensures one job cannot tamper with another, persist on the host, or reach systems it does not need.
Controls: 7 (5 Baseline, 2 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| ISO-01 — Baseline | Ephemeral build environments | Each job runs in a fresh runner, VM or container that is destroyed when the job ends. | Runner configuration; autoscaling or job lifecycle settings |
| ISO-02 — Baseline | No self-hosted runners for untrusted code | Self-hosted runners are not attached to public repositories or to pipelines that build untrusted contributions. | Runner group assignments |
| ISO-03 — Baseline | Hardened runner images | Runner images are minimal, patched and run jobs as non-root; the host container socket is not exposed to jobs. | Runner image definition; image vulnerability scan |
| ISO-04 — Baseline | Runners segregated by trust level | Production deployment runners are separate from general build runners and accept only approved pipelines. | Runner group and tag mapping |
| ISO-05 — Baseline | CI/CD server hardening | Self-managed CI/CD servers are patched; plugins are inventoried and unused ones removed; script consoles are restricted. | Version and plugin inventory; patch records |
| ISO-06 — Advanced | Network egress restrictions | Runners can reach only required registries and endpoints; arbitrary outbound traffic is blocked. | Network policy or firewall rules |
| ISO-07 — Advanced | Cache isolation | Build caches are scoped by branch or trust level and are not shared between untrusted and release builds. | Cache configuration |
06 Dependency and Third-Party Integration Security
Most of the code in a modern build comes from outside the organization: open-source packages, base images, CI plugins and reusable actions. These controls make that code visible, pinned and reviewed before it is trusted.
Controls: 8 (5 Baseline, 3 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| SCA-01 — Baseline | Software composition analysis on every build | Dependencies are checked for known vulnerabilities and license issues, with defined failure thresholds. | SCA reports; threshold policy |
| SCA-02 — Baseline | Locked dependency versions | Lockfiles are committed and builds resolve the same versions every time. | Lockfiles in repositories; build configuration |
| SCA-03 — Baseline | Third-party actions and plugins pinned immutably | Reusable actions, plugins and templates are referenced by commit SHA or digest, not by mutable tags. | Workflow and pipeline files |
| SCA-04 — Baseline | Controlled package sources | Packages come through an internal registry or proxy with scoped namespaces to prevent dependency confusion. | Registry and package manager configuration |
| SCA-05 — Baseline | Approved base images | Container builds use approved, minimal base images pulled by digest and rebuilt regularly. | Approved image list; Dockerfiles |
| SCA-06 — Advanced | Automated, reviewed dependency updates | A dependency update bot opens pull requests that pass the same review and tests as other changes. | Bot configuration; update pull request history |
| SCA-07 — Advanced | Third-party integration governance | Apps, webhooks and integrations with access to source control or CI/CD are inventoried, least-privilege and reviewed. | Integration inventory with granted scopes |
| SCA-08 — Advanced | Health assessment of critical dependencies | Critical open-source dependencies are assessed for maintenance and security practices, for example with OpenSSF Scorecard. | Assessment results for critical dependencies |
07 Build Integrity, SBOM and Artifact Provenance
Consumers of an artifact need to know what it contains, where it was built and that it has not changed since. Software bills of materials (SBOMs), signatures and provenance attestations answer those questions in a form machines can verify at deployment time.
Figure 2. Artifact signing and verification workflow
| Stage | Flow |
|---|---|
| Produce | Isolated build (trusted runner) → Generate SBOM + provenance → Sign artifact & attestations → Artifact registry (immutable tags) |
| Pull | Artifact registry → pull by digest → Deployment request |
| Consume | Deployment request → Verify signature, identity & provenance → Policy decision → Pass: admit & deploy / Fail: block & alert |
Controls: 7 (4 Baseline, 3 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| PRV-01 — Baseline | SBOM for every release artifact | An SBOM in a standard format (SPDX or CycloneDX) is generated for each release and stored with the artifact. | SBOM files linked to released artifacts |
| PRV-02 — Baseline | Build once, promote by digest | The same artifact, identified by immutable digest, is promoted across environments rather than rebuilt for each. | Deployment manifests referencing digests |
| PRV-03 — Baseline | Signed artifacts | Container images and release artifacts are signed, for example with Sigstore or keys held in a key management service. | Signature verification output |
| PRV-04 — Baseline | Protected artifact repositories | Registries use immutable tags, allow writes only from CI identities and apply retention rules. | Registry permission and tag settings |
| PRV-05 — Advanced | Build provenance attestations | The build platform, not user-controlled build steps, generates provenance describing how each artifact was built. | Provenance attestation for sample artifacts |
| PRV-06 — Advanced | Defined SLSA Build level target | Critical artifacts have a stated SLSA Build level target, such as Build L2 or L3, and are assessed against it. | SLSA target and assessment record |
| PRV-07 — Advanced | Reproducible or verifiable builds | Where feasible, critical components can be rebuilt independently and compared to the released artifact. | Rebuild comparison results |
08 Deployment and Cloud Environment Security
Deployment is where pipeline trust turns into production change. These controls govern who and what can deploy, verify artifacts before they run, and keep cloud environments in their declared state.
Controls: 8 (5 Baseline, 3 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| CLD-01 — Baseline | Production deployment approvals | Production deployments require environment protection rules and approval from authorized reviewers. | Environment protection settings; approval history |
| CLD-02 — Baseline | Environment separation | Production and non-production run in separate cloud accounts, subscriptions or projects with separate credentials. | Account or subscription structure |
| CLD-03 — Baseline | Infrastructure as code scanning and plan review | IaC is scanned for misconfigurations and change plans are reviewed before they are applied. | Scan reports; reviewed plan for a recent change |
| CLD-04 — Baseline | Protected infrastructure state | IaC state files are stored remotely, encrypted, access-restricted and locked during changes. | State backend configuration |
| CLD-05 — Baseline | Tested rollback | A documented rollback path exists and has been exercised. | Rollback runbook; date of last test |
| CLD-06 — Advanced | Deploy-time verification | Admission or deployment policy rejects artifacts without a valid signature or provenance from the expected builder. | Policy definition; test showing an unsigned artifact is blocked |
| CLD-07 — Advanced | Drift detection | Deployed infrastructure is regularly compared with its declared configuration and drift raises an alert. | Drift reports; alert configuration |
| CLD-08 — Advanced | Runtime least privilege | Workloads run without privileged containers, with scoped service accounts and enforced pod security standards. | Cluster policies; RBAC configuration |
09 Automated Security Testing and Policy Gates
Automated testing finds issues while they are cheapest to fix. Policy gates turn findings into consistent decisions so the same risk is treated the same way in every pipeline.
Controls: 7 (5 Baseline, 2 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| TST-01 — Baseline | Static application security testing | SAST runs on pull requests and on the main branch, with results visible to developers. | Pipeline configuration; recent SAST results |
| TST-02 — Baseline | Container image scanning | Images are scanned for vulnerabilities before they are pushed or deployed. | Image scan reports |
| TST-03 — Baseline | Defined failure thresholds | Severity thresholds that fail the build are documented and enforced consistently across pipelines. | Threshold policy; failed build examples |
| TST-04 — Baseline | Exception process with expiry | Accepted risks are recorded with an owner, justification and expiry date. | Exception register |
| TST-05 — Baseline | Findings routed to owners | Security findings create tickets in the owning team's backlog with remediation timelines. | Ticket samples; remediation timeline policy |
| TST-06 — Advanced | Dynamic application security testing | DAST runs against a pre-production environment for internet-facing applications. | DAST reports |
| TST-07 — Advanced | Policy as code | Security and compliance rules are expressed as code, for example OPA/Rego or Kyverno, and evaluated in the pipeline. | Policy repository; pipeline evaluation logs |
10 Logging, Monitoring and Incident Response
Pipeline compromises are often discovered late because CI/CD systems sit outside normal security monitoring. These controls bring the pipeline into the security operations scope and prepare teams to respond.
Controls: 6 (4 Baseline, 2 Advanced).
| Control ID | Security Control | Description / Expected Outcome | Evidence Required |
|---|---|---|---|
| MON-01 — Baseline | Centralized CI/CD audit logs | Audit logs from source control, CI/CD platforms, registries and cloud accounts are collected centrally and retained for a defined period. | Log source inventory; retention settings |
| MON-02 — Baseline | Alerts on high-risk changes | Alerts fire on events such as branch protection changes, new administrators, new runners or disabled security checks. | Alert rules; sample alerts |
| MON-03 — Baseline | Tamper-resistant pipeline logs | Build and deployment logs are retained and protected from modification by pipeline users. | Log storage permissions |
| MON-04 — Baseline | CI/CD incident response playbook | Playbooks cover a leaked token, malicious commit, poisoned dependency and compromised runner. | Playbook documents |
| MON-05 — Advanced | End-to-end traceability | Any production artifact can be traced to its commit, build run, approver and deployment. | Trace for a sample production artifact |
| MON-06 — Advanced | Exercised response | Pipeline compromise scenarios are tested at least annually in a tabletop or simulation. | Exercise report and follow-up actions |
11 Security Scoring Model and Assessment Worksheet
Score every control on the four-point scale below. Award a score only when the evidence listed for the control is available; a control that is configured but not enforced, or enforced in only some pipelines, scores no higher than 2. Controls that genuinely do not apply, for example DAST for a pipeline with no deployable application, can be marked N/A and are excluded from the calculation.
| Score | Level | Definition |
|---|---|---|
| 0 | Not Implemented | The control is absent, or there is no evidence that it exists. |
| 1 | Ad Hoc | Partially in place, applied manually or inconsistently, or dependent on individuals. |
| 2 | Implemented | In place across the scoped pipelines and documented, but not technically enforced or regularly tested. |
| 3 | Enforced and Tested | Technically enforced so it cannot be bypassed silently, monitored, and verified through testing or review. |
Calculating maturity
- Category maturity % = points scored in the category ÷ (applicable controls × 3) × 100.
- Overall maturity % = total points across all categories ÷ (total applicable controls × 3) × 100.
- Risk classification applies the bands below to both category and overall percentages.
Figure 3. Security assessment maturity model
| Maturity % | Classification | Interpretation |
|---|---|---|
| 0–39 | Critical Exposure | Core protections are missing; a pipeline compromise is likely to go undetected and reach production. |
| 40–59 | Developing | Some protections exist but are inconsistent; significant gaps remain in Baseline controls. |
| 60–79 | Managed | Baseline controls are largely in place; enforcement and verification are incomplete. |
| 80–89 | Strong | Baseline controls are enforced and several Advanced controls are adopted. |
| 90–100 | Mature | Controls are enforced, tested and monitored, with verifiable artifact integrity end to end. |
Assessment worksheet
Transfer the category totals from Sections 3 to 10. Max points assume every control applies; subtract 3 for each control marked N/A.
| Category | Controls | Max points |
|---|---|---|
| 03 Governance and Source Control | 8 | 24 |
| 04 Identity, Access and Secrets | 8 | 24 |
| 05 Runners and Execution Isolation | 7 | 21 |
| 06 Dependencies and Third Parties | 8 | 24 |
| 07 Build Integrity and Provenance | 7 | 21 |
| 08 Deployment and Cloud | 8 | 24 |
| 09 Security Testing and Policy Gates | 7 | 21 |
| 10 Logging, Monitoring and Response | 6 | 18 |
| Overall | 59 | 177 |
Remediation priority
| Priority | Criteria | Target |
|---|---|---|
| P1 | Any Baseline control scored 0 or 1 in Identity and Secrets (Section 4), Source Control (Section 3) or Runner Isolation (Section 5), or any category classified as Critical Exposure. | Within 30 days |
| P2 | Remaining Baseline controls scored 0 or 1, and any category classified as Developing. | Within 60 days |
| P3 | Baseline controls scored 2, and Advanced controls in categories below Strong. | Within 90 days or next cycle |
12 90-Day Security Improvement Roadmap
The roadmap sequences work so that the controls that most reduce the risk of credential theft and unreviewed change come first, followed by hardening and, finally, verifiable artifact integrity. Adjust the order to the P1 findings from your own assessment.
| Phase | Focus | Key actions | Exit criteria |
|---|---|---|---|
| Days 0–30 | Stabilize | Build the repository and pipeline inventory (GOV-06); run the baseline assessment; enforce SSO and MFA (GOV-05, IAM-07); enable branch protection (GOV-01, GOV-02); turn on secret scanning with push protection and rotate any exposed secrets (IAM-05, IAM-06); set job tokens to read-only by default (IAM-03). | Baseline score recorded; no known exposed secrets; protected branches on all production repositories. |
| Days 31–60 | Harden | Replace static cloud keys with OIDC federation (IAM-01); move to ephemeral, segregated runners (ISO-01, ISO-04); pin third-party actions and plugins by SHA (SCA-03); enforce SCA, SAST and image scanning with thresholds (SCA-01, TST-01–03); centralize audit logs (MON-01). | No static cloud credentials in pipelines; security scans enforced on all tier-1 pipelines. |
| Days 61–90 | Verify | Generate SBOMs and sign artifacts for critical services (PRV-01, PRV-03); promote by digest (PRV-02); pilot provenance and deploy-time verification (PRV-05, CLD-06); publish the incident response playbook (MON-04); reassess and compare scores. | Signed, SBOM-backed releases for critical services; second assessment completed and trend reported. |
13 Ownership Model
Pipeline security spans several teams, and controls without a clear owner tend to decay. The RACI matrix below is a starting point; adapt the roles to your organization's structure. R = Responsible, A = Accountable, C = Consulted, I = Informed.
| Activity | Platform / DevOps | App Security | Dev Teams | Cloud / Infra | Security Ops | Eng. Leadership |
|---|---|---|---|---|---|---|
| Source control rules and code owners | A/R | C | R | I | I | I |
| Pipeline identities and secrets | A/R | C | I | R | I | I |
| Runner build, hardening and isolation | A/R | C | I | R | I | I |
| Dependency and third-party governance | R | A | R | I | I | I |
| SBOM, signing and provenance | A/R | C | C | C | I | I |
| Deployment approvals and cloud guardrails | R | C | C | A/R | I | I |
| Security testing and policy gates | R | A/R | R | C | I | I |
| Monitoring and incident response | C | C | I | C | A/R | I |
| Assessment, roadmap and risk acceptance | R | R | C | C | C | A |
14 References and Technical Glossary
References
- OWASP Top 10 CI/CD Security Risks. OWASP Foundation.
- Supply-chain Levels for Software Artifacts (SLSA), v1.2. OpenSSF.
- NIST SP 800-218, Secure Software Development Framework (SSDF) v1.1. NIST, 2022.
- NIST SP 800-218 Rev. 1 (SSDF v1.2), Initial Public Draft. NIST, 2025.
- NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines. NIST, 2024.
- Defending Continuous Integration/Continuous Delivery (CI/CD) Environments. CISA and NSA, 2023.
- Sigstore. OpenSSF.
- in-toto. CNCF.
- SPDX specification. Linux Foundation.
- CycloneDX specification. OWASP Foundation.
- OpenSSF Scorecard. OpenSSF.
Glossary
| Term | Definition |
|---|---|
| Attestation | A signed statement about an artifact, such as how it was built or what it contains, that can be verified automatically. |
| Branch protection | Source control rules that restrict how changes reach a branch, such as required reviews and status checks. |
| CODEOWNERS | A file that assigns required reviewers to paths in a repository. |
| DAST | Dynamic application security testing: testing a running application from the outside. |
| Dependency confusion | An attack in which a public package with the same name as an internal one is resolved instead of the internal package. |
| Digest | A cryptographic hash that uniquely and immutably identifies an artifact, unlike a tag that can be moved. |
| Drift | Differences between deployed infrastructure and its declared configuration. |
| IaC | Infrastructure as code: defining infrastructure in version-controlled files, for example with Terraform. |
| OIDC federation | Using OpenID Connect tokens issued to a pipeline to obtain short-lived cloud credentials without stored keys. |
| Poisoned pipeline execution | Running attacker-controlled commands in a pipeline by modifying its configuration or the files it executes. |
| Policy as code | Security and compliance rules written as code and evaluated automatically. |
| Provenance | Verifiable information about where, when and how an artifact was built. |
| SAST | Static application security testing: analyzing source code for security flaws without running it. |
| SBOM | Software bill of materials: a machine-readable inventory of the components in an artifact. |
| SCA | Software composition analysis: identifying third-party components and their known vulnerabilities and licenses. |
| SLSA | Supply-chain Levels for Software Artifacts: a framework of incremental levels for build and supply-chain integrity. |
Conclusion
A delivery pipeline is only as trustworthy as its weakest unreviewed link. Teams that score their pipelines against evidence, close Baseline gaps first and build toward SBOM-backed, signed, provenance-verified releases cut the time an attacker can hide inside the build, and gain the audit trail regulators and enterprise customers increasingly expect. The downloadable whitepaper includes the complete fillable assessment worksheet and assessment summary fields for your own scoring cycle.