Software Product Security: Where To Start?

There is plenty of publicly available information about how software development teams can make their products more secure. However, this knowledge is often obscure to software engineers. Developers get stuck in their routine jobs following the usual development cycle with no incentive to learn about security. From initial design specifications to basic functionality and a prototype, to an MVP, to regular customer feature requests, to fixing bugs… On and on goes the feature-centric development cycle, with little or no effort spent on securing the product. Until there is a breach, or the regulator unleashes its wrath on management, or a big client demands actual proof of product security, or an M&A deal requires a demonstration of due diligence.

So the real question is not whether security matters, but when you should start paying attention to it in the product lifecycle — and what you should start with so you avoid the misery of hindsight.

When should you start?

If nothing has gone wrong yet, it seems there is no room for security in development operations. As the engineers build their stuff head-down in the daily routine, spending time and resources on security seems impractical. Until the security risks materialize as a cyber incident or a privacy-watchdog fine, the need for security is not apparent. But when it finally is, a brief analysis often shows that fixing it requires unfeasible changes to the product architecture — and it starts to look easier to rewrite everything from scratch.

Usually, when product teams first reach out to appsec experts, it turns out the penetration test is the first thing about security they have ever done. Sure enough, this first application pentest produces a long list of severe security vulnerabilities. As a result, teams have to reconsider their release dates and spend the following months fixing security flaws. Having learned from their mistakes, developers ask us what they should have done instead.

We answer that the first thing they should have done is hire a security-aware CTO at the very beginning of their journey. A capable, security-savvy technology leader would pay enough attention to appsec matters along the way. First of all, they would dedicate appropriate resources to establishing and running proper application security practices. But more importantly, they would point the team toward the right software security documentation from day one.

As the patriarch of software threat modeling, Adam Shostack, once put it: you have to threat model early — and if you already have a data flow diagram of your product, it is already late. Simply because the team has already made many design decisions, and now they will have to reconsider them. The same is true of every other security practice: it always feels a little bit late to start. But it is also never too late.

It is good to start early, but there can be economic and strategic obstacles to doing so. Startups, for instance, do not usually think about software security at the outset because they have a lot of other things to worry about, and the success rate of startups is low enough that additional sunk costs are hard to justify. That does not make them negligent — it makes them rational. They simply have higher-priority threats in their broader threat model. And when the time comes for application security to claim its place on the priority list, due attention must be paid to it.

So when do you start, really? By now you can probably see that there is no objectively right or wrong place or time. Start when you can and when you need to. The more important question is what to start with. For the sake of everything that is holy to you, do not start by buying an overpriced “solution” that promises to “solve” all your problems — or at least, that the salespeople tell you it will.

Start with a SAMM self-assessment

Start small: do an OWASP SAMM self-assessment, which is straightforward to work through using their supporting toolbox. It is just a set of simple questions you ask yourself, recording the results as you go; the rest works like magic. With the assessment in hand, mark down the practices you need to start doing, the practices you need to do better, and the practices you do not have to worry about yet (or at all). Those chosen practices are your roadmap — start planning their implementation now. There are even ready-made reference roadmaps for common types of software development teams.

The practices you cannot skip

The list of practices in your initial software security program will vary, but a few are non-negotiable. These are Threat Modeling, Secure Architecture Design, Secure Development, and Security Testing.

• Threat Modeling surfaces design-level risk before you have written the code that bakes it in. As Shostack’s point above makes clear, this is the practice with the highest cost of delay.
• Secure Architecture Design turns the output of threat modeling into concrete decisions — trust boundaries, authentication and authorization models, secrets handling, and the defaults your product ships with.
• Secure Development is the day-to-day discipline: secure-by-default libraries, code review with security in mind, and developers who know which classes of bug to avoid.
• Security Testing verifies the result — a mix of automated scanning in the pipeline and human-driven testing such as a pentest, which catches what the tooling cannot.

Run these four well and your product can be planned, designed, implemented, and delivered securely. You will still find bugs in a pentest — but far fewer, and at a much lower average risk level.

Where to find the real guidance

We are an OWASP fan club, and that is exactly why we push back on teams that treat the OWASP Top 10 as the finish line. The four crucial practices above are documented in depth across OWASP’s project portfolio:

• SAMM — the Software Assurance Maturity Model, your assessment and roadmap framework.
• ASVS — the Application Security Verification Standard, the actual requirements you verify a product against.
• WSTG — the Web Security Testing Guide, the methodology your testing follows.
• Proactive Controls — the secure-development controls developers should build in from the start.
• Cheat Sheet Series — concise, task-specific implementation guidance.

There are many more OWASP documentation projects, but start with these and seek additional guidance only when you find them lacking the detail you need.

And please — I beg you — do not use the OWASP Top 10 as a standard. The Top 10 is an awareness document. It exists to raise the floor of what developers know about web application risk, and it does that job superbly. What it is not is a verification standard, a test plan, or a definition of “done.” Every edition — including the latest 2025 list — is ten awareness categories, not a checklist you can certify against. When you need something to build and measure a program on, reach for ASVS, WSTG, and SAMM. When you want to explain to a new developer why any of it matters, hand them the Top 10.

How BSG can help

Where in the software product lifecycle does security come into play? Everywhere — and the cheapest time to address it is always earlier than it feels. If you would rather not learn that lesson from a first pentest full of critical findings, the practical move is to assess where you stand, build a roadmap, and start closing the gaps before they harden into architecture.

To bring a development team up to speed, we also run a dedicated training program built on SAMM. The Developer Application Security Awareness Training covers:

• fundamental cybersecurity concepts
• secure engineering principles
• application threat modeling
• secure development
• and security testing.

During the training, we teach where to find the correct data and guidance on application security and how to apply it in practice. After the course, the development team understands what appsec is, knows which practices it needs, and walks away with a clear implementation roadmap. Read more about the training on our website.