DevSecOps integrates security into every stage of the software delivery lifecycle rather than treating it as a separate phase at the end. Shift-left means moving security checks to earlier stages of development — left on the timeline. The economic argument: fixing a vulnerability in a developer's editor costs almost nothing (minutes of developer time). Fixing the same vulnerability after it reaches production costs orders of magnitude more — incident response, customer notification, regulatory fines, reputation damage. Practical shift-left: pre-commit hooks detect secrets before they reach Git. SAST scans code on every commit. Dependency scanning checks for known CVEs in libraries on every build. Container scanning checks Docker images before they are pushed. IaC scanning checks Terraform and Helm for misconfigurations before they deploy. The goal is for security findings to appear in the developer's pull request, not in a penetration test report three months later.

Speed is the enemy of security adoption. Developers disable slow security checks. Design for speed. Order tools by speed and fail fast: gitleaks secrets scan runs in 10 seconds — first in pipeline, blocks everything else if it fails. semgrep SAST runs in 30-60 seconds — runs in parallel with dependency scanning. Trivy image scan runs in 60-90 seconds — runs after build. Slow tools (DAST, full dependency tree analysis) run nightly, not on every commit. Separate blocking from informational: CRITICAL vulnerabilities block the pipeline. HIGH vulnerabilities create issues but do not block (unless in a security-sensitive service). MEDIUM/LOW are reported as dashboard metrics. Caching: cache dependency vulnerability databases locally so Trivy does not re-download on every run. Use ignore-unfixed: true in Trivy — skip CVEs that have no patch available (developers cannot act on them anyway). At HPE: our full DevSecOps pipeline adds 3 minutes to a CI run. Without it: we had a dependency vulnerability in production for 8 months before a pentest found it.

Triage first, then fix. Step 1: assess impact. Read the CVE details — is it exploitable in your context? A remote code execution CVE in a library you only use for local file parsing is low actual risk. Step 2: identify affected services. Your CI/CD pipeline with dependency scanning (Trivy, npm audit, Dependabot) should tell you which services use the vulnerable version. Query your artifact registry if you have an SBOM (Software Bill of Materials). Step 3: patch systematically. Update the dependency version. Run the test suite. For critical CVEs with active exploitation: patch production within 24 hours if possible. For others: next scheduled deployment cycle. Step 4: verify. After patching each service, re-run Trivy to confirm the CVE is resolved. Step 5: prevent recurrence. If Dependabot or Renovate is not already configured for automated dependency updates, enable it now. Set up weekly automated PR creation for dependency updates. Enable GitHub security advisories notifications. Step 6: SBOM. Maintain a Software Bill of Materials for all services so next CVE query takes minutes not hours.

SAST (Static Application Security Testing): analyses source code without executing it. Finds: SQL injection patterns, hardcoded credentials, insecure function calls, buffer overflows. Tools: Semgrep, SonarQube, Checkmarx. Runs fast, can run on every commit. Cannot find issues that only appear at runtime. DAST (Dynamic Application Security Testing): tests a running application by sending attack payloads. Finds: XSS vulnerabilities, authentication bypasses, API security issues, runtime misconfigurations. Tools: OWASP ZAP, Burp Suite. Requires a deployed application so cannot run on every commit. Usually runs in staging environment. SCA (Software Composition Analysis): analyses your dependencies and third-party libraries for known CVEs. Finds: vulnerable npm packages, outdated Java jars with known exploits. Tools: Trivy, OWASP Dependency Check, Snyk, Dependabot. Uses CVE databases (NVD, OSV). Can run on every commit on the dependency manifest files. All three are complementary: SAST for your code, SCA for your dependencies, DAST for your running application. A mature DevSecOps pipeline uses all three at appropriate stages.