Secure Development Lifecycle: What an SDL Looks Like for a 20-Person Engineering Team

Most secure development lifecycle frameworks were written with enterprise organisations in mind: dedicated AppSec engineers, security gates at every stage, formal risk acceptance workflows. When a 20-person engineering team tries to implement those frameworks as written, the result is usually a document that nobody reads and a process that nobody follows. The overhead is real. The capacity is not.

The answer is not to skip security in the development process. It is to design a version that fits the actual team. A right-sized SDL adds genuine security value at each stage without requiring resources that a small team does not have. We work with engineering teams of this size regularly, and the pattern is consistent: a well-designed lightweight SDL delivers more actual security improvement than a theoretically correct but unimplemented enterprise framework.

What a Minimal SDL Actually Covers

A functional SDL for a small engineering team covers four stages: design, build, test, and deploy. At the design stage, that means a brief threat modelling review before significant features are built, not a multi-day workshop. At the build stage, it means security linting and dependency checks built into the IDE and the pull request process so they happen automatically rather than by individual discipline.

At the test stage, it means regular automated scanning plus an annual or bi-annual external pen test. At the deploy stage, it means infrastructure-as-code review and secrets management checks before anything reaches production. None of these are novel ideas. The value of an SDL is that they are connected into a consistent process rather than occurring sporadically depending on who happens to remember to do them.

Where Small Teams Usually Start

The highest-value starting point for most 20-person teams is the build stage. Automated static analysis and dependency vulnerability scanning integrated into the CI pipeline catches a large proportion of common vulnerabilities before they ever reach review. This costs almost nothing in engineering time once configured, and it runs on every commit without requiring anyone to remember to trigger it.

The second priority is usually secrets management. Hardcoded credentials, API keys committed to version control, and misconfigured environment variable handling account for a disproportionate share of serious incidents in small engineering teams. A secrets scanning tool in the pipeline and a clear policy about how credentials are handled in development environments is a high-impact, low-effort control. Start there before attempting to implement anything more sophisticated.

The Design Review That Fits One Sprint

Threat modelling intimidates many small teams because they have seen the enterprise version, which involves days of workshops and formal documentation. The version that works for a 20-person team is a 60-to-90 minute structured conversation before building a significant new feature or integration. The output is a short list of identified risks and agreed mitigations, not a formal document.

The questions to answer in that conversation are straightforward: what data does this feature handle, who should and should not be able to access it, what happens if it is compromised, and what are the most plausible ways an attacker would try to abuse it. Running this conversation once per significant feature takes roughly half a sprint planning slot and catches the category of issues that typically show up later in pen tests as architectural findings with high remediation cost.

Measuring Whether Your SDL Is Working

The most useful metric for a small team is finding recurrence in external security testing. If you run a pen test and fix the findings, then run another pen test six months later and see the same categories of finding, the SDL is not working. If recurrence is low, it is working. Track it explicitly.

Other useful signals include the number of security findings caught in code review versus production, the time between a vulnerability being discovered in a dependency and it being patched, and whether threat model outputs are actually referenced when features are built. These are process signals, not just outcome signals, and they tell you where the SDL is being followed and where it is being bypassed.

• Automated scanning in CI/CD as the minimum baseline
• Secrets management policy and tooling before anything else
• 60-to-90 minute threat model per significant feature
• Annual external pen test with tracked remediation
• Finding recurrence rate as the primary SDL effectiveness metric

If your engineering team is building an SDL from scratch or auditing what you have, we can help you design something that will actually get used. Contact us at info@cyberlinx.com.au.