Application security is often reduced to a tool purchase — run a scanner, get findings, done. That framing misses three of the four legs holding up the table. Chris Romeo, CEO of Kerr Ventures and former Chief Security Advocate at Cisco, has spent over 25 years in security spanning incident response, engineering, and executive leadership. He founded Security Journey (exited in 2022) and hosts multiple award-winning podcasts including the Application Security Podcast and the Threat Modeling Podcast. In this episode, he breaks down the four pillars of application security, explains how to introduce threat modeling without burying developers in noise, and shares what he actually did to secure his own startup on zero budget.
You can read the complete transcript of the episode here >
What are the four pillars of application security?
Chris frames AppSec as a table with four legs — remove any one and the table falls over:
- People: Developers write code, but universities do not teach them to write secure code. The people pillar means investing in developers who understand how to avoid SQL injection, cross-site scripting, and the rest of the OWASP Top 10. It requires continuous education, not a one-time event.
- Process: A repeatable secure development lifecycle that ensures every product goes through the same set of security controls — security requirements, threat modeling, code review, security testing — regardless of team or project.
- Tools: SAST, DAST, SCA, RASP, IAST, CWPP — the acronyms are endless. Tools make people more efficient and enact the process. But they are one leg of the table, not the whole table.
- Governance: Dashboards, metrics, and traceability. Once you reach a certain maturity, you need to measure whether people are learning, whether the process is being followed, and whether tool findings are being addressed. This concept, which Chris credits to Alyssa Miller, is what separates an ad hoc effort from a scalable program.
The common mistake: teams equate AppSec with their static analysis tool. That is one leg of a four-legged table.
What are the biggest application security mistakes organizations make?
Chris identifies three categories of recurring failures:
- The OWASP Top 10 still applies: The list is now data-driven (not opinion-based), and the vulnerabilities it documents remain pervasive. Organizations that dismiss it as “basic stuff” are often the ones still shipping those exact issues.
- Unprotected CI/CD pipelines: Build systems are part of the attack surface. If an attacker gets into your pipeline, they can inject libraries, modify code, and pollute builds at the source. Pipeline security is application security.
- Software supply chain risk: The problem is not just first-level dependencies — it is transitive dependencies several layers deep. Vulnerable components are still being downloaded and included in packages at alarming rates. Understanding this requires software composition analysis tools that go beyond surface-level scanning into the full dependency graph, which is core to code security practices.
How should threat modeling be introduced into the SDLC?
Chris offers both the purist and the realist perspective:
- The purist view: Threat modeling should happen the moment a developer picks up a user story and starts thinking about design — before a single line of code is written. In agile, that design phase is compressed into the gap between grabbing the story and starting to code.
- The realist view: Organizations that start threat modeling have mountains of existing code already in production. They cannot delete everything and start fresh. They must retrofit threat models onto deployed features while simultaneously threat modeling new work.
- How to close the gap: The gap exists because companies did not start threat modeling when they started building. The answer is integrating people, process, tools, and governance into existing applications — carefully, slowly, and without burying developers in noise.
The worst thing you can do: turn on a SAST tool against an un-scanned codebase, generate a thousand Jira tickets, and assign them all to one developer. That developer will think security people are morons and fight every future initiative. Careful introduction is critical—effective vulnerability management requires prioritization—and this principle is exactly why shifting culture from friction to flow matters so much.
Why does Chris recommend STRIDE for getting started with threat modeling?
Chris shares his personal journey with STRIDE — a love-hate-love relationship:
- Phase 1 (love): He discovered STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) and found it helpful for teaching. It simplifies categories of threats into something memorable.
- Phase 2 (hate): He got overconfident and tried more complicated methodologies. People struggled. They did not know where to start or what they were supposed to be doing.
- Phase 3 (love again): He came back to STRIDE because there is beauty in simplification. It provides a foundational layer that helps people understand the basics before graduating to more advanced approaches like MITRE ATT&CK, attack trees, or LINDDUN for privacy.
The key insight: people should outgrow STRIDE — and that is fine. But it gives them the starting vocabulary to move forward. More advanced frameworks like MITRE ATT&CK can layer on top once the foundation is solid.
Should threat modeling be continuous?
Yes. Chris frames it as “continuous threat modeling” — the same principle as continuous deployment and continuous delivery:
- Systems change and features change constantly in agile environments.
- New threats emerge that did not exist previously (five years ago, nobody was thinking about supply chain attacks — now entire companies exist to solve them).
- A one-time threat model captures a snapshot that immediately becomes stale.
The mindset shift required: threat modeling is not a checkbox activity. It is a living practice that evolves with the software, similar to how vulnerability management and supply chain security require ongoing attention rather than periodic audits.
What should resource-constrained startups do for product security?
Chris speaks from direct experience — he built his own startup’s security program on effectively zero budget:
- Threat model yourself: He personally threat modeled the architecture and early designs, then taught developers to do the same. It costs nothing but time and sets the culture from day one.
- Open source SAST in the pipeline: A free static analysis tool executed on every commit. If it threw an error, the code could not merge. Developers built the habit of writing secure code because the pipeline enforced it.
- Open source SCA in the pipeline: NPM audit for Node dependencies, bundler-audit for Ruby. These break the build on known vulnerabilities in packages. Zero cost, immediate protection for the software supply chain.
- The enterprise customer payoff: When prospects asked “what do you do about security?” the answer was specific and credible: threat modeling, SAST, SCA — for a five-person company. That answer wins contracts.
For teams with slightly more budget, Chris recommends OWASP Dependency-Check as a battle-tested SCA tool that has been in production use for years.
Can AI solve application security problems?
Chris sees AI as a force multiplier, not a replacement:
- For developers: AI can make regular developers 10x developers by scaffolding code, handling boilerplate, and letting them focus on the specialized logic. But someone still needs to validate that the scaffolded code is secure.
- For SOC analysts: Microsoft’s Copilot for Security automates the legwork of correlating disparate data feeds, letting analysts reach conclusions faster rather than spending time gathering information.
- For AppSec specifically: AI could eventually provide secure coding guidance inline — advising developers on secure patterns as they write code. But it cannot replace the people, process, or governance layers.
The framing Chris uses: AI improves all four legs of the AppSec table. It helps people be better, tools be smarter, and governance track more effectively. But it does not replace any leg. It is not doing application security for you — at least not yet.
How does Chris rate common security practices?
- Training employees only during onboarding: Rated 1 (worst). Education must be continuous. If you teach developers for one week and turn them loose for the rest of their career, there is no reinforcement. By six months, they will have forgotten almost everything. Monthly security touchpoints — exercises, challenges, reinforcement — are what make learning stick.
- Regularly testing an incident response plan: Rated 5 (best). Chris ran incident response for a large web hosting company and experienced firsthand what happens without a plan: chaos, expensive on-the-fly decision-making, and higher risk of mistakes. Having a plan fleshed out in advance — who to communicate with, what steps to follow — is worth the investment many times over.
- Granting unrestricted access to speed up developers: Rated 1 (worst). It works at 5 people; it collapses at 5,000. If everyone has admin access and someone drops all tables, you cannot trace who did it. Build least-privilege habits from the start — containerization exists precisely because developers used to deploy code without understanding their dependency environment.
