This post explains how to operationalize ECC 2-10-3 from the Compliance Framework by embedding vulnerability management into your DevSecOps pipelines — covering asset inventory/SBOMs, shift-left scans (SAST/SCA/IaC), image and runtime scans, triage and SLAs, evidence collection for auditors, and low-cost patterns a small business can implement today.
Build an authoritative inventory and generate SBOMs early
Start by ensuring the Compliance Framework requirement is grounded in an authoritative asset inventory: every repository, container image, VM/template and IaC template must be recorded. Generate an SBOM (Software Bill of Materials) during the build stage using tools such as syft (syft packages -o cyclonedx=sbom.json) or SPDX/CycloneDX exporters. Store SBOMs as build artifacts and push them to your artifact repository (e.g., Nexus/Artifactory/Harbor) so an auditor can see which components were present in any build. For IaC, include the template as part of the SBOM generation process so the Compliance Framework can verify what was declared versus what was deployed.
Shift-left scanning: integrate SAST, SCA and IaC checks into CI
Embed static analysis and dependency checks in pull-request pipelines so developers get immediate feedback. Implement at least the following: SAST (e.g., Semgrep or SonarQube) to catch common code issues, SCA (e.g., Dependabot, Snyk, Grype) to flag vulnerable libraries, and IaC scanning (e.g., Checkov, tfsec, Terrascan) to detect insecure cloud configurations. Configure the pipeline to run these tools on PRs and to fail the build for critical/high findings or create a blocking policy only if the team agrees; lower severity issues can create tickets automatically. Include explicit commands in CI steps (for example, run semgrep --config=auto, run trivy fs . --severity CRITICAL,HIGH --format json -o results.json) and publish the JSON result artifacts for compliance evidence.
Scan images and enforce policies at build and deploy time
Scan container images immediately after build using Trivy, Clair or Grype and produce a machine-readable report (e.g., JSON). Enforce policy gates: for example, block images with Critical CVEs or images older than a defined base by more than X days. Use image signing (cosign) and attestation to bind a scanned image to its SBOM and to allow only signed images to be deployed. At deploy time enforce policy with an admission controller such as OPA Gatekeeper or Kyverno to prevent unapproved images from hitting Kubernetes clusters. Store scan metadata in the registry (Harbor or Artifact Registry) so deployment systems and auditors can query whether a given image passed required scans.
Perform DAST in staging and monitor runtime for emerging vulnerabilities
Dynamic scanning (DAST) belongs in pre-production/staging pipelines: run active scans (OWASP ZAP or commercial DAST tools) against staging endpoints to identify runtime issues and configuration problems. Complement this with runtime detection in production (Falco, Wazuh, EDR telemetry) and monitoring of vendor CVE feeds and threat intelligence. For example, if a CVE is published for an OS package used in production, your runtime detectors and registry metadata should surface which deployed images are affected so you can triage and remediate quickly.
Triage, prioritization and SLA-driven remediation workflows
Automation must feed into a triage workflow: convert scan findings into tickets (Jira/GitHub Issues) with pre-populated fields (severity, CVE id,affected artifact, exploit maturity, SBOM link). Prioritize using a composite risk score that combines CVSS, exploit maturity (e.g., presence of PoC), internet exposure (public-facing vs internal), and asset criticality. For Compliance Framework alignment, define SLAs and document them: Critical = 24–48 hours, High = 7 days, Medium = 30 days, Low = backlog with periodic review. Automate SLA tracking with dashboards and keep historical evidence of when tickets were opened and closed to demonstrate compliance to auditors.
Evidence, reporting and mapping to Compliance Framework control 2-10-3
To meet ECC 2-10-3 produce and retain the following artifacts: CI build logs showing SAST/SCA/IaC runs, SBOMs per build, image scan reports, admission controller logs blocking deployments (if used), tickets for each vulnerability with remediation evidence (merge/patch and deploy), and dashboards that show SLA attainment. Configure retention policies so these artifacts are available for the Compliance Framework retention window. Provide mapping documentation that links these artifacts to the control: e.g., "Control 2-10-3 - pipeline evidence: build-123 SBOM, scan-report-123.json, ticket-456 (closed), deployment-log-789".
Low-cost stack and a small-business scenario
A small business can meet ECC 2-10-3 without large budget by combining open-source tooling: use GitHub Actions or GitLab CI as the pipeline runner, semgrep for SAST, Dependabot for dependency updates, Trivy/Grype for image and filesystem scans, Checkov/tfsec for IaC, syft for SBOMs, and Kyverno for admission policies in Kubernetes. Example scenario: a two-developer SaaS team adds a GitHub Action that runs semgrep and trivy on every PR, automatically raises a GitHub Issue for High/Critical CVEs, and requires the issue to be closed before merging; SBOMs are uploaded to S3 and a weekly job aggregates open CVEs into a simple dashboard used for compliance reporting.
Risks of not implementing integrated vulnerability management
Failing to integrate vulnerability management into DevSecOps leads to slow detection, inconsistent remediation, and untracked exposure — increasing the likelihood of successful exploitation, data loss, regulatory penalties and failed audits under the Compliance Framework. Operationally, the organization will experience firefighting after production incidents, longer mean time to remediate (MTTR), and loss of customer trust; from a compliance perspective, auditors will flag lack of continuous controls and absence of evidence for ECC 2-10-3.
In summary, implement an automated, pipeline-first vulnerability management approach to satisfy ECC 2-10-3: generate SBOMs, run SAST/SCA/IaC at pull-request time, scan images and enforce deployment policies, run DAST in staging and runtime monitoring in production, automate triage and SLAs, and collect build artifacts and tickets as audit evidence — all of which can be achieved cost-effectively by combining open-source tools and a small set of operational rules for triage and documentation.
