Skip to content

Compliance standards

Every finding produced by the scanner carries a list of ControlRef objects: references to controls in registered compliance standards. The same check can evidence controls in multiple standards at once.

flagship · 10/10

OWASP Top 10 CI/CD

The reference framework for CI/CD security risks. Full coverage across every supported provider.

10 controls · 1014 checks evidenced

CIS AWS Foundations

CI/CD-relevant subset of the CIS AWS benchmark. IAM, S3, CloudTrail, KMS hardening.

14 controls · 62 checks evidenced

CIS Azure Foundations

CI/CD-relevant subset of the CIS Microsoft Azure benchmark. Entra ID, storage, Key Vault, container registry, monitoring.

35 controls · 50 checks evidenced

CIS GCP Foundations

CI/CD-relevant subset of the CIS Google Cloud Platform benchmark. IAM, Cloud Storage, Cloud KMS, Artifact Registry, logging.

30 controls · 50 checks evidenced

CIS GitHub Benchmark

Platform-side posture for a GitHub org or repo. Sections 1.1 (Code Changes), 1.4 (Third-Party), 1.5 (Code Risks).

28 controls · 138 checks evidenced

CIS Kubernetes

CIS Kubernetes Benchmark, Section 5 (Policies). RBAC, Pod Security Standards, NetworkPolicy, Secrets, namespaces.

24 controls · 47 checks evidenced

CIS Supply Chain

CIS Software Supply Chain Security Guide. Source, build, dependency, and artifact controls.

25 controls · 988 checks evidenced

NIST SSDF

Secure Software Development Framework, the federal SSDLC reference (SP 800-218).

13 controls · 984 checks evidenced

NIST 800-53

Federal control catalog (CI/CD subset). Maps findings to AC, AU, CM, IA, SI, SR families.

26 controls · 994 checks evidenced

NIST CSF 2.0

Cybersecurity Framework. Govern, Identify, Protect, Detect, Respond, Recover.

23 controls · 994 checks evidenced

NIST 800-190

Application Container Security Guide, image, registry, runtime, host hardening.

12 controls · 548 checks evidenced

SLSA Build Track

Supply-chain Levels for Software Artifacts. Provenance, hermeticity, signing posture.

7 controls · 695 checks evidenced

PCI DSS v4.0

Payment Card Industry Data Security Standard, CI/CD subset (logging, secret management, change control).

13 controls · 994 checks evidenced

NSA/CISA ESF

Enduring Security Framework. Securing the Software Supply Chain (developer, customer, supplier).

24 controls · 995 checks evidenced

OpenSSF Scorecard

Open-source project security health metrics. Pinned-deps, branch-protection, signing-keys, dangerous workflows.

10 controls · 720 checks evidenced

S2C2F

Secure Supply Chain Consumption Framework, ingest, inventory, scan, rebuild, fix.

11 controls · 394 checks evidenced

OSC&R

Open Software Supply Chain Attack Reference. MITRE ATT&CK-style matrix for software supply chain attacks: 12 tactics, 86 techniques.

86 controls · 725 checks evidenced

SOC 2

Trust Services Criteria. Audit-friendly mappings for Security, Confidentiality, and Availability.

11 controls · 994 checks evidenced

How to read severity

Every check ships at a fixed severity level. The scale is the same across providers and standards, so a CRITICAL finding in one place means the same thing as a CRITICAL finding anywhere else. Each standards page links back here rather than restating the table.

Level What it means Examples
CRITICAL Active exploit primitive in the workflow as written. Treat as P0: a default scan path lands an attacker on a secret, an RCE, or production write access without further effort. Hardcoded credential literal, branch ref pointing at a known-compromised action, signed-into-an-unverified registry.
HIGH Production-impact gap that requires modest attacker effort or a second condition to weaponize. Remediate this sprint; the secondary condition is usually already present in real pipelines. Action pinned to a floating tag, sensitive permissions on a low-popularity action, mutable container tag in prod.
MEDIUM Significant defense-in-depth gap. Not directly exploitable on its own but disables a control whose absence widens the blast radius of a separate compromise. Backlog with a deadline. Missing branch protection, container without resource limits, freshly-published dependency consumed before the cooldown window.
LOW Hygiene / hardening issue. Not a vulnerability on its own but raises baseline posture and reduces audit friction. Missing CI logging retention, SBOM without supplier attribution, ECR repo without scan-on-push.
INFO Degraded-mode signal. The scanner couldn't reach an API or parse a config and surfaces the gap so the operator knows coverage was incomplete. No finding against the workload itself. CB-000 CodeBuild API access failed, IAM-000 IAM enumeration failed.

Using standards at runtime

pipeline_check --list-standards                                                 # list registered standards
pipeline_check --pipeline aws --standard owasp_cicd_top_10                      # filter to one
pipeline_check --pipeline aws --standard owasp_cicd_top_10 --standard nist_ssdf # multiple

Omit --standard to include every registered standard.

Architecture

A standard is pure data, no code. Each one is a Python module in pipeline_check/core/standards/data/ that defines a module-level STANDARD object:

from ..base import Standard

STANDARD = Standard(
    name="my_standard",
    title="My Compliance Standard",
    version="1.0",
    url="https://example.com",
    controls={
        "CTRL-1": "First control",
        ...
    },
    mappings={
        # check_id → list of control_ids it evidences
        "IAM-001": ["CTRL-1"],
        ...
    },
)

Register it in pipeline_check/core/standards/__init__.py and the scanner, CLI (--standard, --list-standards), and reporters pick it up automatically.

Why data, not code

  • Re-use across checks: a single check like S3-002 can evidence multiple standards (OWASP CICD-SEC-9 and CIS 2.1.1) without the check itself knowing about any standard.
  • Easy to audit: the mapping table lives in one file, not scattered across Finding constructor calls.
  • Easy to extend: adding ISO 27001 or a bespoke internal policy is one new Python module.