How do organisations decide where to place application security controls in the SDLC?

Why This Matters for Security Teams

Security control placement in the SDLC is really a question of when risk becomes cheapest to detect and fix. The earlier a control runs, the more context it has and the less rework it creates. That is why teams increasingly place policy checks in the IDE, commit pipeline, build stage, and deployment gates instead of waiting for a late-stage scan. NIST’s SP 800-53 Rev 5 Security and Privacy Controls remains a useful anchor for control objectives, but the implementation pattern now has to fit developer workflow.

The practical issue is that modern applications are assembled from code, dependencies, secrets, and infrastructure definitions, so a single check at the end of the pipeline misses most of the exposure. NHIMG research on The State of Secrets in AppSec shows how often secrets handling breaks down in daily development, and that gap is exactly why control placement matters. In practice, many security teams encounter preventable leakage only after code has already been merged, built, and distributed, rather than through intentional early prevention.

How It Works in Practice

Control placement should follow the order of developer activity, not the order of audit reporting. Start with inline guidance in the IDE for dependency risk, hard-coded secrets, insecure patterns, and IaC misconfigurations. Then add commit-time checks for lightweight validation, followed by build-time gates for deeper analysis such as SAST, dependency review, policy-as-code, and secret scanning. Deployment gates should enforce the final release decision, but they should not be the only control point.

This layered approach works because different SDLC stages answer different questions. The IDE helps prevent mistakes before they exist. The commit stage catches obvious issues before they spread. The build stage evaluates aggregated risk across code, packages, and configuration. The deploy stage enforces release policy, exception handling, and evidence collection. Guidance from Ultimate Guide to NHIs is especially relevant when the same pipeline also handles service accounts, tokens, and other NHI-bearing automation. For standards alignment, teams often map these checkpoints to OWASP Top 10 findings, dependency controls, and platform guardrails.

• IDE controls should be advisory and fast, or developers will bypass them.
• Commit controls should be low-friction and focus on high-confidence findings.
• Build controls should combine scanning with policy decisions that can fail the pipeline.
• Deployment controls should validate environment-specific risk, approvals, and exception records.

Teams get better results when they separate detection from enforcement and reserve hard failures for issues that are both actionable and well understood. These controls tend to break down in monorepos with high build churn because scan latency and false positives make developers ignore the pipeline.

Common Variations and Edge Cases

Tighter control placement often increases build friction, so organisations have to balance developer velocity against assurance. That tradeoff is real, especially in fast-moving product teams, regulated environments, and shared platform pipelines where the same control can affect dozens of services.

Current guidance suggests three common variations. First, some teams place only advisory checks in the IDE and reserve enforcement for merge and release gates. Second, platform engineering teams often centralise policy in reusable pipeline templates so individual squads do not implement controls differently. Third, organisations with heavier risk profiles may add release approval for sensitive changes, but best practice is evolving and there is no universal standard for this yet.

Edge cases usually involve context that static checks cannot fully evaluate: generated code, ephemeral environments, vendor-managed pipelines, and secrets injected at runtime. In those cases, control placement should be paired with runtime telemetry and least-privilege access to limit blast radius. NHIMG’s coverage of JetBrains GitHub plugin token exposure and Code Formatting Tools Credential Leaks shows why developer tooling itself can become part of the attack path, not just the target. Organisations should treat control placement as a workflow design problem, not a checklist problem.

Related resources from NHI Mgmt Group

• How should organisations decide whether to integrate AI agents with other security platforms through protocol-based connections?
• How do organisations decide which entitlements deserve the strongest controls and monitoring?
• How should organisations unify security, privacy, and AI risk governance without creating duplicate controls work?
• How do organisations decide where AI data security controls should sit?