Modern software ships 10 times a day. Traditional annual audits are architecturally incompatible with this reality. This module teaches you to govern security inside the development pipeline — embedding controls where code is written, tested, and deployed.
DevSecOps integrates security into every phase of software development — not as a gate at the end of the pipeline, but as a continuous, automated activity throughout. The core insight: finding a vulnerability in development costs $80. Finding it in production after a breach costs $8,000+ (NIST cost data). Security earlier is security cheaper.
The three pillars: People — security training for developers, security champions embedded in dev teams, shared responsibility culture. Process — threat modeling in design, security requirements in user stories, security review in sprint retrospectives. Technology — automated security testing in CI/CD, SAST, DAST, SCA, container scanning.
IBM System Science Institute data shows security defect cost escalates exponentially by phase:
| Phase Found | Relative Cost to Fix |
|---|---|
| Design / Requirements | 1× |
| Development / Coding | 6× |
| Testing / QA | 15× |
| Production (pre-breach) | 45× |
| Post-Breach | 100×+ |
This data is the business case for DevSecOps investment. Every $1 spent on security in design phase saves $45–$100 in post-production remediation.
Traditional audit assumes stable, periodic change cycles. DevOps environments ship dozens of changes daily. The audit question shifts from "review the last change" to "is the change management process controlled?" GRC professionals must audit the pipeline and its automated gates — not individual changes.
Security user stories and abuse cases defined alongside functional requirements. Regulatory requirements translated into technical security requirements (GDPR → data minimization in data model, PCI-DSS → tokenization of card data). Threat modeling begins at architecture level. Security acceptance criteria defined before any code is written.
Threat Modeling (STRIDE/PASTA/Attack Trees): systematically identify threats to the architecture. STRIDE framework: Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege. For each identified threat, define mitigating controls before the design is approved. Security architecture review by a security architect before design sign-off.
Secure coding guidelines enforced. IDE security plugins provide real-time vulnerability detection as code is written. Secret scanning prevents credentials from being committed to version control (GitGuardian, git-secrets). Peer code review with security checklist. Developer security training tailored to language and framework.
SAST (Static Application Security Testing): scans source code for vulnerability patterns without executing it. SCA (Software Composition Analysis): identifies known CVEs in open-source dependencies (SBOM generation). Secret scanning: ensures no credentials or keys committed to the build artifact. Infrastructure-as-Code (IaC) scanning: Terraform, CloudFormation templates scanned for misconfigurations before deployment.
DAST (Dynamic Application Security Testing): tests the running application for vulnerabilities — SQL injection, XSS, authentication flaws. Penetration testing of staging environment. Container image scanning for known CVEs. API security testing. Compliance policy checks run against the deployed environment before promotion to production.
Runtime Application Self-Protection (RASP): detects and blocks attacks within the running application. SIEM log ingestion from application. Regular vulnerability scanning. Patch management SLAs. Penetration testing (annual minimum). Bug bounty programs. Continuous compliance monitoring (CSPM, cloud policy enforcement).
A well-governed CI/CD pipeline has mandatory security gates that cannot be bypassed. GRC professionals audit these gates as the change management control:
| Gate | Tool Category | Blocks Deploy If… | GRC Control Objective |
|---|---|---|---|
| Secret Scanning | GitGuardian, Trufflesec | Credentials or keys found in code | Prevent credential exposure via source control |
| SAST Scan | Snyk, Checkmarx, SonarQube | Critical/High findings exceed threshold | Prevent known vulnerability classes in code |
| SCA / Dependency Check | Snyk, OWASP Dependency-Check | CVSS Critical CVE in dependency | Prevent deployment of vulnerable libraries |
| Container Scan | Trivy, Clair, Anchore | Critical CVE in base image | Prevent deployment of vulnerable containers |
| IaC Security Scan | Checkov, tfsec, Terrascan | High-severity misconfiguration in IaC | Prevent infrastructure misconfigurations |
| DAST Scan | OWASP ZAP, Burp Suite API | Critical runtime vulnerability found | Prevent exploitable runtime flaws |
| Policy Compliance Check | OPA/Rego, AWS Config Rules | Compliance policy violation detected | Enforce Compliance as Code before deployment |
| Change Approval | ServiceNow, Jira | Required approval not obtained | Maintain change authorization audit trail |
Every gate in this table represents a control. GRC professionals should audit: (1) Do all these gates exist? (2) Can any gate be bypassed? (3) Is there a documented exception process for gate overrides? (4) Are override decisions logged with business justification and approval?
The OWASP Top 10 is the most widely recognized application security awareness document. For GRC professionals, each risk maps to governance requirements:
Most critical OWASP risk. GRC control: authorization testing in every DAST scan, quarterly access review of application roles, principle of least privilege in application design reviews.
Data in transit and at rest unencrypted. GRC control: cryptography standard mandating TLS 1.2+, AES-256, key management policy, crypto library approved list, automated scan for cleartext transmission.
Untrusted input executed as code. GRC control: SAST rules detecting injection patterns, code review checklist item, developer training on parameterized queries, DAST testing for injection.
Fundamental design flaws. GRC control: mandatory threat modeling in design phase, security architecture review gate before development begins, abuse case documentation.
Unnecessary features enabled, default credentials. GRC control: IaC scanning, CSPM continuous monitoring, hardening baseline standards, automated configuration compliance.
Known CVEs in libraries. GRC control: SCA in CI pipeline, SBOM requirement, 30-day SLA for critical CVE patching, approved component library management.
Compliance as Code expresses governance policies as machine-executable rules that are automatically enforced in CI/CD pipelines and cloud environments. Key technologies:
A general-purpose policy engine. Policies written in Rego language are enforced at deployment time. Example: a Rego policy that blocks deployment of containers running as root, or that requires all S3 buckets to have encryption enabled before Terraform apply completes.
Cloud-native compliance policy engines. Rules continuously evaluate cloud resource configurations against defined policies. Non-compliant resources are flagged, and some rules can automatically remediate (enable encryption, revoke public access). Audit evidence is automatically generated.
Terraform, CloudFormation, and Kubernetes YAML scanned by Checkov, tfsec, or Terrascan before apply/deploy. Misconfigurations — public S3 buckets, overprivileged IAM roles, unencrypted EBS volumes — caught before infrastructure is provisioned.
Every pipeline run generates compliance artifacts: scan results, policy check outcomes, approval records. These artifacts are automatically stored in the GRC platform or evidence repository. SOC 2 and ISO 27001 evidence collection becomes automated — the audit preparation time drops from weeks to hours.
Traditional audits request 12 months of change records and review them after the fact. Agile auditing works differently:
In a team deploying 50 times/day, you cannot review each deployment. Instead: audit whether the CI/CD pipeline gates are well-designed, mandatory, and cannot be bypassed. A controlled pipeline ensures every change is controlled.
Pipeline artifacts (scan results, approval records, deployment logs) accumulate continuously. The auditor reviews the system that generates evidence, not individual transactions. Sample from the automated log, not from each sprint.
Security audit activities embedded in sprint retrospectives and quarterly reviews. Rather than a separate audit event, GRC activities are part of the development cadence — sprint security review, quarterly penetration test, monthly compliance dashboard review.
Not all sprints are equal. Sprints deploying changes to high-risk components (authentication, payment processing, PHI-touching code) receive higher audit attention. Low-risk UI changes receive less. Risk-tiered sampling aligns effort to actual risk.
You are auditing a DevOps team's CI/CD pipeline for a financial services company. The pipeline deploys directly to production with no manual approval gate. Complete each security gate assessment — SAST, SCA, secrets scanning, image signing, and DAST — documenting findings in audit language.