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.
Why this control matters (Compliance Framework context)
At 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.
How CI/CD and DevSecOps map to the control
CI/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.
Pipeline security patterns
Implement "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.
Artifacts, provenance, and cryptographic controls
Use 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.
Practical implementation steps for a small business
Small 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.
Example: GitHub Actions + AWS (concise snippet)
Small team example pipeline steps (conceptual):
- name: Checkout
uses: actions/checkout@v4
- name: Run SAST
uses: returntocorp/semgrep-action@v1
with:
config: open-source-rules
- name: Generate SBOM
run: |
docker build -t myapp:$ .
syft packages docker:myapp:$ -o spdx-json > sbom-$.json
- name: Scan image
uses: aquasecurity/trivy-action@v0.1.0
with:
image-ref: myapp:$
- name: Sign image
run: |
cosign sign --key $COSIGN_KEY myregistry/myapp:$
- name: Deploy (uses AWS roles)
uses: aws-actions/amazon-ecs-deploy-task-definition@v1
Key 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.
Compliance tips, evidence, and best practices
Make 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.
Risk of not implementing the requirement
Failure 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.
In 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.
