Treat security as part of the development process, not a separate gate at the end. Developers should focus on writing code, while AppSec teams provide guidance, training, and review patterns that help teams reduce risk early. The practical goal is secure-by-default engineering, supported by standards, automated checks, and collaboration rather than blame or manual heroics.
Build security into the workflow, not after the merge
Security works best when it is embedded in how teams design, code, test, and ship software. The development team does not need to become a security team; instead, the process should make secure choices easier than insecure ones, with guardrails that catch common mistakes early and a clear path to ask for help when the risk is unfamiliar.
That usually means shifting left on the decisions that are easiest to influence before release: dependency choice, input handling, secrets handling, authZ assumptions, logging, and release checks. It also means making security expectations explicit in the same places engineers already work, such as code review, CI pipelines, and architecture discussions, so security becomes part of normal delivery rather than a separate queue.
For teams formalising that approach, the NIST SSDF (SP 800-218) is a practical baseline for secure software development, and the OWASP API Security Top 10 is useful where application interfaces are a major attack surface.
One statistic is a useful reality check here: 96% of organisations store secrets outside secrets managers in vulnerable locations such as code, config files, and CI/CD tools. That is not a developer competence problem alone, it is a process design problem, which is why secure defaults and automated checks matter so much.
What AppSec should provide so developers stay focused on product work
AppSec adds value when it translates security into patterns developers can apply without becoming specialists. The most effective support is concrete and repeatable: reference architectures, approved libraries, secure code patterns, prebuilt CI checks, threat-modelling prompts, and short review guidance for the application types the organisation actually builds.
The important judgement is to distinguish “developer-owned” from “security-owned.” Developers should own implementation quality and fix issues in their code. AppSec should own the standards, the review criteria, and the higher-risk decisions where teams need specialist interpretation, such as exception handling, cryptographic choices, or whether a design introduces an unacceptable exposure path.
Where teams need help scaling consistent practice, OWASP SAMM is a useful maturity reference for building software assurance into delivery, and the OWASP Cheat Sheet Series gives developers practical implementation guidance they can apply during normal engineering work.
Internal examples also matter. A breach such as the Google Firebase misconfiguration breach shows how developer-facing misconfigurations can expose secrets at scale, while the Nx Package Attack illustrates why build and dependency controls belong in the development process itself.
What good looks like in practice
Good teams reduce security friction by standardising the path to “secure enough to ship.” That includes approved templates, linting and scanning that run automatically, dependency controls, secret detection, clear ownership for exceptions, and review patterns that focus attention on the parts of the codebase that can actually change risk.
What to prioritise: start with the controls that remove the most common failure modes, not the most exotic ones. In practice, that usually means secrets, dependencies, authentication and authorisation assumptions, unsafe defaults, and build integrity before more advanced tooling.
What to verify: teams should be able to show that insecure patterns are blocked or flagged early, that exceptions have owners and expiry dates, and that security guidance is available at the point of use rather than buried in policy documents.
Practitioner takeaway: The goal is not to make every developer a specialist, it is to make secure behaviour the easiest behaviour and reserve specialist judgement for the cases where the design meaningfully changes risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8, NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.IP — Information Protection Processes and Procedures | Secure-by-default software delivery depends on defined engineering processes. |
| GV.OC — Organizational Context | Teams need clear ownership boundaries between developers and AppSec. | |
| PR.AC — Identity Management, Authentication and Access Control | Secure development must address authn/authz assumptions in code. | |
| Recommendation — Embed secure coding, review, and change practices into the SDLC. Define who owns secure coding, review, and escalation decisions. Review application access decisions and enforce least privilege in design. | ||
| CIS Controls v8 | 16 — Application Software Security | This FAQ is about building security into software development workflows. |
| 14 — Security Awareness and Skills Training | Developers need targeted guidance, not full specialist conversion. | |
| Recommendation — Adopt secure development and testing controls for applications. Train engineers on the secure patterns they use most often. | ||
| OWASP Non-Human Identity Top 10 | NHI-03 — Secrets and Credential Management | The answer explicitly depends on avoiding secrets sprawl in development. |
| NHI-05 — Privilege Creep and Excessive Permissions | Secure-by-default engineering requires reducing default overprivilege. | |
| Recommendation — Detect, store, and rotate secrets through approved managed workflows. Limit default permissions and remove unnecessary privileged access paths. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Where software handles identity flows, assurance affects design decisions. |
| AAL — Authenticator Assurance Level | Secure application design often includes the strength of authentication flows. | |
| Recommendation — Align identity-proofing strength with the application risk being built. Choose authenticator strength that matches the sensitivity of the software. | ||
| NIST Zero Trust (SP 800-207) | JEA — Just-Enough-Access | Development and deployment should restrict actions to the minimum needed. |
| Recommendation — Constrain automation and service actions to just enough access. | ||
Related resources from NHI Mgmt Group
- Why does software development become riskier when teams defer security work until maintenance?
- How should security teams reduce false positives in software composition analysis without slowing developers down?
- How should security teams integrate security into the software development lifecycle without slowing delivery?
- How should security teams embed continuous penetration testing into AI-assisted software development without slowing delivery?
