This post gives practical, actionable guidance on using CI/CD and DevSecOps practices to satisfy the intent of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control SC.L2-3.13.2 — focusing on secure system communications, cryptographic protections, and build/artifact provenance — with small-business examples, configuration tips, and evidence-gathering advice for auditors.
\n\nAt Level 2, the Compliance Framework expects organizations to protect Controlled Unclassified Information (CUI) in transit and to demonstrate that systems and artifacts are built, distributed, and configured with appropriate security controls. For most small businesses, the challenge is operationalizing those protections consistently and creating verifiable evidence that secure communications, cryptographic configuration, and artifact provenance are enforced across development and deployment pipelines.
\n\nCI/CD pipelines and DevSecOps practices are the natural mechanism to enforce the control's requirements in an automated, repeatable way. Key mappings include: (1) pipeline gates enforce cryptographic and transport configuration checks (TLS ciphers, HSTS, mutual TLS where required); (2) artifact signing and attestations provide provenance for builds; (3) secrets and key management integration ensures keys never live in plaintext in repos or pipeline logs; and (4) automated scanning (SAST/SCA/DAST/IaC) ensures no regressions. Together these provide both technical control and the audit trail auditors expect.
\n\nImplement \"shift-left\" checks as required status checks on pull requests: SAST (e.g., Semgrep, SonarQube), SCA (Dependabot, Snyk), IaC scanning (Checkov, tfsec), and secrets scanning (git-secrets, detect-secrets). Enforce branch protection rules so merges cannot occur unless all required checks pass. In the CD stage, perform container/image scanning (Trivy, Anchore), runtime policy checks (OPA/Gatekeeper), and attest artifact provenance (in-toto/in-toto-run). Store all pipeline logs and artefact metadata for the retention period required by your compliance policy, and link them to specific releases.
\n\nUse an artifact repository (e.g., Amazon ECR, GitHub Packages, Nexus) and sign artifacts using sigstore/cosign or GPG so you can prove which source revision produced a deployed binary. Generate an SBOM (Software Bill of Materials) with syft during the build step and attach it as an artifact. For cryptography and transport security: enforce TLS 1.2+ with strong cipher suites at load balancers and APIs, automate certificate issuance/rotation with ACME/Let's Encrypt or a managed CA (AWS ACM), and integrate KMS (AWS KMS, Azure Key Vault) into your CD pipeline so encryption keys and HSM-backed key IDs are referenced from the pipeline without exposing secrets.
\n\nSmall businesses with limited staff can meet the control efficiently by standardizing on hosted CI/CD and managed cloud services to reduce operational burden. Example step-by-step plan: (1) Inventory data flows to identify where CUI moves across services. (2) Adopt a hosted CI (GitHub Actions/GitLab CI) and enable branch protection and required checks. (3) Add SAST and SCA in PR checks (Semgrep + Dependabot). (4) Scan IaC templates and block PRs that fail critical checks. (5) Build SBOMs and sign every build artifact; store signed images in ECR/ACR with immutability enabled. (6) Use cloud KMS to manage encryption keys and configure all services to use TLS with enforced policies. (7) Produce and retain build logs, signed attestations, SBOMs, and deployment records as audit evidence.
\n\nSmall team example pipeline steps (conceptual):
\n- name: Checkout\n uses: actions/checkout@v4\n\n- name: Run SAST\n uses: returntocorp/semgrep-action@v1\n with:\n config: open-source-rules\n\n- name: Generate SBOM\n run: |\n docker build -t myapp:${{ github.sha }} .\n syft packages docker:myapp:${{ github.sha }} -o spdx-json > sbom-${{ github.sha }}.json\n\n- name: Scan image\n uses: aquasecurity/trivy-action@v0.1.0\n with:\n image-ref: myapp:${{ github.sha }}\n\n- name: Sign image\n run: |\n cosign sign --key $COSIGN_KEY myregistry/myapp:${{ github.sha }}\n\n- name: Deploy (uses AWS roles)\n uses: aws-actions/amazon-ecs-deploy-task-definition@v1\nKey points: store cosign keys in a vault (HashiCorp Vault or GitHub Secrets backed by KMS), require signed images for deployment, and ensure the deploy step uses short-lived cloud credentials via OIDC rather than long-lived secrets.
\n\nMake auditability a first-class output of your pipeline: keep immutable build logs, signed artifacts, SBOMs, PR histories, and policy decisions (OPA/Sentinel) centralized and retained according to policy. Use policy-as-code to codify what “pass” looks like (e.g., minimum TLS version, dependencies with no critical CVEs, signed images). For small businesses, leverage managed services (ACM, KMS, Cloud Audit Logs) to reduce overhead and produce high-quality evidence. Regularly exercise incident response and recovery (test rollbacks, canary failures) and record these exercises.
\n\nFailure to implement these controls increases the risk of CUI being intercepted, injected, or exfiltrated via insecure communications or malicious/tainted artifacts. Without artifact provenance and cryptographic assurances, you can't prove what code was deployed or who built it — a major audit deficiency and a supply-chain risk. Operational risks include prolonged breach detection times, inability to roll back to known-good artifacts, and potential contract loss or penalties for non-compliance.
\n\nIn summary, meeting SC.L2-3.13.2 is achievable for small businesses by baking cryptographic configurations, secure transport enforcement, artifact signing, SBOMs, and pipeline-based policy checks into CI/CD. Use managed services where possible, automate evidence collection, apply least privilege to keys and runners, and require signed, scanned artifacts for production deployments — these steps both reduce risk and produce the documentation auditors expect.
", "plain_text": "This post gives practical, actionable guidance on using CI/CD and DevSecOps practices to satisfy the intent of NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 Control SC.L2-3.13.2 — focusing on secure system communications, cryptographic protections, and build/artifact provenance — with small-business examples, configuration tips, and evidence-gathering advice for auditors.\n\nWhy this control matters (Compliance Framework context)\nAt Level 2, the Compliance Framework expects organizations to protect Controlled Unclassified Information (CUI) in transit and to demonstrate that systems and artifacts are built, distributed, and configured with appropriate security controls. For most small businesses, the challenge is operationalizing those protections consistently and creating verifiable evidence that secure communications, cryptographic configuration, and artifact provenance are enforced across development and deployment pipelines.\n\nHow CI/CD and DevSecOps map to the control\nCI/CD pipelines and DevSecOps practices are the natural mechanism to enforce the control's requirements in an automated, repeatable way. Key mappings include: (1) pipeline gates enforce cryptographic and transport configuration checks (TLS ciphers, HSTS, mutual TLS where required); (2) artifact signing and attestations provide provenance for builds; (3) secrets and key management integration ensures keys never live in plaintext in repos or pipeline logs; and (4) automated scanning (SAST/SCA/DAST/IaC) ensures no regressions. Together these provide both technical control and the audit trail auditors expect.\n\nPipeline security patterns\nImplement \"shift-left\" checks as required status checks on pull requests: SAST (e.g., Semgrep, SonarQube), SCA (Dependabot, Snyk), IaC scanning (Checkov, tfsec), and secrets scanning (git-secrets, detect-secrets). Enforce branch protection rules so merges cannot occur unless all required checks pass. In the CD stage, perform container/image scanning (Trivy, Anchore), runtime policy checks (OPA/Gatekeeper), and attest artifact provenance (in-toto/in-toto-run). Store all pipeline logs and artefact metadata for the retention period required by your compliance policy, and link them to specific releases.\n\nArtifacts, provenance, and cryptographic controls\nUse an artifact repository (e.g., Amazon ECR, GitHub Packages, Nexus) and sign artifacts using sigstore/cosign or GPG so you can prove which source revision produced a deployed binary. Generate an SBOM (Software Bill of Materials) with syft during the build step and attach it as an artifact. For cryptography and transport security: enforce TLS 1.2+ with strong cipher suites at load balancers and APIs, automate certificate issuance/rotation with ACME/Let's Encrypt or a managed CA (AWS ACM), and integrate KMS (AWS KMS, Azure Key Vault) into your CD pipeline so encryption keys and HSM-backed key IDs are referenced from the pipeline without exposing secrets.\n\nPractical implementation steps for a small business\nSmall businesses with limited staff can meet the control efficiently by standardizing on hosted CI/CD and managed cloud services to reduce operational burden. Example step-by-step plan: (1) Inventory data flows to identify where CUI moves across services. (2) Adopt a hosted CI (GitHub Actions/GitLab CI) and enable branch protection and required checks. (3) Add SAST and SCA in PR checks (Semgrep + Dependabot). (4) Scan IaC templates and block PRs that fail critical checks. (5) Build SBOMs and sign every build artifact; store signed images in ECR/ACR with immutability enabled. (6) Use cloud KMS to manage encryption keys and configure all services to use TLS with enforced policies. (7) Produce and retain build logs, signed attestations, SBOMs, and deployment records as audit evidence.\n\nExample: GitHub Actions + AWS (concise snippet)\nSmall team example pipeline steps (conceptual):\n- name: Checkout\n uses: actions/checkout@v4\n\n- name: Run SAST\n uses: returntocorp/semgrep-action@v1\n with:\n config: open-source-rules\n\n- name: Generate SBOM\n run: |\n docker build -t myapp:${{ github.sha }} .\n syft packages docker:myapp:${{ github.sha }} -o spdx-json > sbom-${{ github.sha }}.json\n\n- name: Scan image\n uses: aquasecurity/trivy-action@v0.1.0\n with:\n image-ref: myapp:${{ github.sha }}\n\n- name: Sign image\n run: |\n cosign sign --key $COSIGN_KEY myregistry/myapp:${{ github.sha }}\n\n- name: Deploy (uses AWS roles)\n uses: aws-actions/amazon-ecs-deploy-task-definition@v1\n\nKey points: store cosign keys in a vault (HashiCorp Vault or GitHub Secrets backed by KMS), require signed images for deployment, and ensure the deploy step uses short-lived cloud credentials via OIDC rather than long-lived secrets.\n\nCompliance tips, evidence, and best practices\nMake auditability a first-class output of your pipeline: keep immutable build logs, signed artifacts, SBOMs, PR histories, and policy decisions (OPA/Sentinel) centralized and retained according to policy. Use policy-as-code to codify what “pass” looks like (e.g., minimum TLS version, dependencies with no critical CVEs, signed images). For small businesses, leverage managed services (ACM, KMS, Cloud Audit Logs) to reduce overhead and produce high-quality evidence. Regularly exercise incident response and recovery (test rollbacks, canary failures) and record these exercises.\n\nRisk of not implementing the requirement\nFailure to implement these controls increases the risk of CUI being intercepted, injected, or exfiltrated via insecure communications or malicious/tainted artifacts. Without artifact provenance and cryptographic assurances, you can't prove what code was deployed or who built it — a major audit deficiency and a supply-chain risk. Operational risks include prolonged breach detection times, inability to roll back to known-good artifacts, and potential contract loss or penalties for non-compliance.\n\nIn summary, meeting SC.L2-3.13.2 is achievable for small businesses by baking cryptographic configurations, secure transport enforcement, artifact signing, SBOMs, and pipeline-based policy checks into CI/CD. Use managed services where possible, automate evidence collection, apply least privilege to keys and runners, and require signed, scanned artifacts for production deployments — these steps both reduce risk and produce the documentation auditors expect." }, "metadata": { "description": "Practical CI/CD and DevSecOps steps to meet NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2 control SC.L2-3.13.2, with tool examples, code provenance, and small-business implementation guidance.", "permalink": "/how-to-use-cicd-and-devsecops-practices-to-achieve-nist-sp-800-171-rev2-cmmc-20-level-2-control-scl2-3132.json", "categories": [], "tags": [] } }