BUILDING A BULLETPROOF GRC PROGRAM — Part 2 of 8: Applying GRC Frameworks to Your Secure SDLC…

Every phase of your software development lifecycle has governance, risk, and compliance responsibilities. This part maps them explicitly — so you can see exactly where controls live, what risk they mitigate, and what compliance evidence they produce.

Phase 1: Plan And Requirements

Governance responsibility:

• Define security requirements upfront based on your chosen framework. Don't wait until code is written to think about security. Requirements should include authentication needs, data classification, encryption requirements, and access control expectations.

Risk responsibility:

• Perform threat modeling to identify risks early. This feeds your risk register with specific, actionable entries before a single line of code is written.

Compliance responsibility:

• Document which regulations apply to this feature. If it touches payments, PCI-DSS applies. If it handles EU user data, GDPR applies. If it processes health information, HIPAA applies. Document this now, not at audit time.

Key outputs from this phase:

• Threat model document (STRIDE, DREAD, or attack trees)

• Security requirements embedded in user stories

• Compliance requirements checklist for the feature

• New entries in the risk register

⚠ REAL-WORLD: The 2021 Log4Shell vulnerability (CVE-2021–44228) affected virtually every Java application. Organizations that performed threat modeling and maintained software bills of materials (SBOMs) during the planning phase were able to identify affected assets within hours. Those without any asset inventory or dependency tracking spent weeks discovering exposure.

Phase 2: Code

Governance responsibility:

• Enforce coding standards via linters, formatters, and pre-commit hooks. Standards are not suggestions — they are automated enforcement of policy decisions.

Risk responsibility:

• Secrets scanning prevents credential exposure. Hardcoded credentials remain one of the most common and easily exploitable vulnerabilities. Pre-commit hooks catch this before code even reaches the repository.

Compliance responsibility:

• Peer code review requirements satisfy SOC 2 CC8.1 (logical access controls over changes) and ISO 27001 A.14.2.2 (system change control procedures). Every approved PR is compliance evidence.

Technical controls at this phase:

• Pre-commit hooks — secrets scanning (gitleaks, truffleHog), linting, formatting

• IDE security plugins — real-time vulnerability feedback while coding

• Branch protection rules — require minimum 1 approver, require status checks

• Coding standards documentation — accessible and enforceable

⚠ REAL-WORLD: In 2022, Toyota exposed 296,019 customer records because a developer accidentally committed an access key to a public GitHub repository. The key remained exposed for nearly five years. A simple pre-commit hook scanning for credentials would have prevented this entirely.

Phase 3: Build And CI

Governance responsibility:

• SAST and SCA gates enforce the policy that no known-vulnerable code ships to production. This is governance automated — the pipeline enforces what the policy document states.

Risk responsibility:

• Catches code-level and supply chain vulnerabilities before merge. Every finding blocked at this stage is a vulnerability that never reaches production.

Compliance responsibility:

• Automated scan results map directly to:

• SOC 2 CC7.1 (detection and monitoring procedures)

• NIST CSF DE.CM-4 (malicious code detection)

• PCI-DSS 6.5.x (secure development practices)

• ISO 27001 A.14.2.1 (secure development policy)

Technical controls at this phase:

• SAST scanning (Semgrep, CodeQL, SonarQube) — finds code vulnerabilities

• SCA scanning (Snyk, Trivy, Dependabot) — finds vulnerable dependencies

• Container image scanning (Trivy, Grype) — finds vulnerabilities in base images

• Build fails automatically on high or critical severity findings

⚠ REAL-WORLD: The 2024 XZ Utils backdoor (CVE-2024–3094) was a supply chain attack where a malicious contributor spent two years gaining trust before inserting a backdoor into a widely-used compression library. Organizations with SCA scanning that flagged unexpected changes in critical dependencies were protected. This incident demonstrates why SCA in CI is not optional — it is a critical supply chain defense.

Phase 4: Test

Governance responsibility:

• DAST and security testing are required before any production release. This is policy, not a nice-to-have.

Risk responsibility:

• Finds runtime vulnerabilities that static analysis misses — authentication bypasses, authorization flaws, injection vulnerabilities that only manifest when the application runs.

Compliance responsibility:

• Penetration test reports satisfy PCI-DSS Requirement 11.3 and SOC 2 CC4.1 (monitoring of controls). DAST results demonstrate ongoing security testing beyond static analysis.

Technical controls at this phase:

• DAST (OWASP ZAP, Burp Suite) running against staging environment

• Security-focused integration tests covering authentication, authorization, and input validation

• Fuzz testing for critical parsers and APIs

• Periodic penetration testing (at least annually, or after major changes)

Phase 5: Deploy

Governance responsibility:

• Change management policy is enforced. No unauthorized production deployments. Every change has a documented reason, an approver, and a rollback plan.

Risk responsibility:

• Infrastructure as Code scanning prevents cloud misconfigurations before they reach production — open security groups, public S3 buckets, overly permissive IAM roles.

Compliance responsibility:

• Signed artifacts and deployment logs serve as audit evidence. Change records prove that changes were authorized and controlled.

Technical controls at this phase:

• IaC scanning (Checkov, tfsec, KICS) — catches misconfigurations before apply

• Least-privilege IAM policies — no wildcard permissions

• Signed artifacts and SLSA provenance — tamper-evident builds

• Change approval workflows — documented, auditable decisions

• Rollback capability — every deploy can be reversed

⚠ REAL-WORLD: The 2019 Capital One breach (100 million records) was caused by a misconfigured WAF and overly permissive IAM role in AWS. IaC scanning would have flagged the overly broad permissions. Change management would have required review of the IAM configuration. Both governance controls were absent.

Phase 6: Operate And Monitor

Governance responsibility:

• Incident response policy defines how the organization detects, triages, responds to, and recovers from security events. Response is not improvised — it follows a documented playbook.

Risk responsibility:

• Runtime monitoring detects threats as they materialize. The risk register informed what to monitor for; monitoring proves whether risks are being realized.

Compliance responsibility:

• Logging and incident records satisfy:

• NIST CSF DE.AE (anomalies and events detected)

• SOC 2 CC7.2 (monitoring for anomalies)

• PCI-DSS 10.x (logging and monitoring requirements)

Technical controls at this phase:

• Security logging with centralized collection (SIEM integration)

• Runtime application protection and anomaly detection

• Incident response runbooks for each severity level

• Periodic access reviews (quarterly) to remove stale permissions

• Post-incident reviews feeding lessons back into risk register

The Complete Mapping: How Each Control Serves All Three Pillars

Here is how common controls simultaneously satisfy governance, risk, and compliance:

SAST scanning in CI:

• Governance → enforces secure coding policy

• Risk → mitigates code injection and data exposure risks

• Compliance → evidence for SOC 2 CC7.1, PCI 6.5.x, ISO A.14.2.1

Peer code review with branch protection:

• Governance → enforces code review policy

• Risk → reduces human error and catches malicious insertions

• Compliance → evidence for SOC 2 CC8.1, ISO A.14.2.2

Secrets scanning in pre-commit and CI:

• Governance → enforces credential management policy

• Risk → prevents credential exposure (a top breach vector)

• Compliance → evidence for SOC 2 CC6.1, ISO A.9.4.3

IaC scanning before deployment:

• Governance → enforces infrastructure security policy

• Risk → prevents cloud misconfigurations

• Compliance → evidence for SOC 2 CC6.6, NIST PR.IP

Incident response within defined SLAs:

• Governance → enforces incident response policy

• Risk → limits blast radius and exposure duration

• Compliance → evidence for SOC 2 CC7.3, NIST RS.RP-1

Quarterly access reviews:

• Governance → enforces least-privilege access policy

• Risk → removes stale accounts that could be compromised

• Compliance → evidence for SOC 2 CC6.2, ISO A.9.2.5

Evidence Flow: Pipeline To Audit

When controls are embedded in the pipeline, evidence accumulates automatically:

• Pipeline scan runs → results stored as CI artifacts (timestamped, immutable)

• Branch protection logs → prove required checks were active and passing

• PR approval records → prove peer review occurred with specific approvers

• Deploy logs → prove change management process was followed

• All of the above → maps to specific framework control requirements

When auditors arrive, you pull reports — you don't scramble.

Practical Example: Semgrep In Ci As A Grc Control

If you have a Semgrep workflow in your CI pipeline, here is what that single tool accomplishes from a GRC perspective:

• As governance: It enforces your secure coding policy. Code literally cannot merge to main with critical vulnerabilities. The policy states "all code must be scanned" — the pipeline makes it impossible to skip.

• As risk mitigation: It catches injection flaws, data exposure patterns, authentication bypasses, and insecure cryptography before they reach production. Each blocked finding is a risk that never materialized.

• As compliance evidence: Every pull request generates a scan artifact. Across a year, that is continuous proof that detection procedures are active — exactly what SOC 2 CC7.1 requires.

• Ownership: DevOps team maintains the pipeline workflow. Security team maintains the Semgrep rule set. Both accountabilities are clear and documented.

Your Semgrep scan is not just a developer tool. It is a governance control that generates compliance evidence as a natural byproduct of normal development work. No extra effort required.

Key Takeaways

• Every SDLC phase carries GRC responsibilities — from threat modeling during design through incident response in production. There is no "security-free" phase.

• Technical tools are governance controls — reframe how you think about your security tooling. Each tool enforces a policy, mitigates a risk, and generates evidence.

• Automation makes governance sustainable — manual gates don't scale. Automated gates enforce policy consistently and generate evidence without human bottlenecks.

• Evidence accumulates naturally — when controls are embedded in the pipeline, audit evidence is a byproduct, not extra work. You're always audit-ready.

• Real breaches map to specific SDLC gaps — Toyota (code phase), Capital One (deploy phase), SolarWinds (build phase), XZ Utils (build phase). Every phase matters.

What Comes Next

In Part 3, we explore how ServiceNow GRC operationalizes all of this at scale — turning the controls and evidence from your pipeline into a managed, auditable, board-reportable governance program. We cover policy management, risk registers, compliance frameworks, audit management, and executive reporting.

Previous: Part 1 — Foundations of GRC

Next: Part 3 — ServiceNow GRC — Operationalizing Governance at Scale