In the fast-paced world of modern software development, security can sometimes feel like a daunting chore. However, shifting our mindset to view security as a “beautiful craft” integrated directly into the Software Development Life Cycle (SDLC) can dramatically change an organization’s posture.
To explore this, we draw insights from a recent conversation with Kalyani “Kaylee” Pawar, an AppSec engineer at the Series F drone unicorn, Zipline. Kalyani’s diverse background—spanning adversary emulation, pen testing, compliance, and application security—provides a practical roadmap for startups and enterprises alike.
You can read the complete transcript of the epiosde here >
Baking Security In: The Threat Modeling Process
When should you start threat modeling? Kalyani offers a simple analogy: baking a cake. If you want a cake to taste delightful, you add the sugar at the beginning, not at the end. Threat modeling must happen as early as possible, ideally in the requirements and design phase.
This “shift left” approach is crucial because discovering and fixing a vulnerability post-deployment—when users are already on the app—consumes significantly more resources.
To effectively implement threat modeling without getting overwhelmed:
- Scope it down: Do not let a massive system design diagram paralyze you. Zoom into a specific feature, like authentication, and detail it thoroughly.
- Involve the right people: Bring together business stakeholders, developers, and security experts with both offensive and defensive perspectives.
- Create detailed Data Flow Diagrams (DFDs): Make them as concise and beautiful as possible, as you will refer to them throughout the cycle.
- Brainstorm use cases: Think through your user stories, such as the differing access levels between a seller and an admin.
- Embrace imperfection: Your first threat model will not be perfect, and that is completely fine. Start generating ideas and translate your findings into checklists and templates that can be scaled to other teams.
For teams lacking a dedicated security expert, formal definitions of threat modeling can be overly complex. Boil it down to four basic questions: What is the system? What can go wrong? What can we do about it? Did we do a good enough job?. For beginners, the STRIDE methodology is a highly recommended foundational framework. If your goal is to bake Governance, Risk, and Compliance (GRC) into the process from the start, consider the PASTA model.
Remember, threat modeling is not a one-and-done activity. Think of it like building a sandcastle on a beach: you must constantly account for changing winds, waves, and seagulls. As your tech stack evolves and new attack vectors (like Log4j) emerge, your security must adapt in tandem.
Taming the Vulnerability Management Monster
There is no magic cheat code to eliminate all vulnerabilities; enterprise backlogs can easily reach into the six figures.
To tackle this efficiently, organizations should move beyond generic CVSS scores, which are often not applicable to a company’s specific context. Instead, build a custom prioritization algorithm based on:
- Exploitability: Is it a zero-day? Is it being exploited in the wild?
- Environment: Is the vulnerability on a public-facing website, or is it heavily walled off?
- Business Impact: What happens to the business if this is exploited?
Once you generate tailored severity levels (e.g., a “Sev 1” that must be fixed immediately versus one that can wait seven days), use an efficient Kanban ticketing system. Provide clear justifications and metrics in the ticket so it doesn’t get lost in the developer’s backlog.
Scaling Security: Ownership, Champions, and Culture
In fast-paced startups, a single AppSec engineer might support 200 developers. To scale, you must make developers the owners of their feature’s security. This fosters education through osmosis, teaching them how to spot vulnerable packages and exploit paths.
Building a Security Champion program is also highly effective. When security requests face pushback due to sprint bandwidth, a champion embedded in the engineering team can translate the risk into developer language to secure manager buy-in.
When communicating risk:
- Only escalate to upper management if the situation is a true “dumpster fire”.
- If developers push back, write a simple exploit to demonstrate the factual reality of the vulnerability.
- Foster a blameless culture during post-mortems—there is no point crying over spilled milk.
- Celebrate the wins! Remediating vulnerabilities is tough work, so reward and highlight teams that dedicate time to fixing them.
Compliance is Just the Foundation
In the cloud—the “Wild West” of the modern digital era—security misconfigurations rank high on the OWASP Top 10.
While frameworks like SOC2 or HIPAA are critical, they should be viewed merely as the foundation of a house (the wiring and plumbing). True security is the motion-detecting lights and camera systems you build on top of that foundation. You must continuously build beyond compliance because regulations lag behind the current threat landscape, and customers actively demand robust, up-to-date security measures like MFA to protect their networks.
Quick Security Practices Ratings
To wrap up, here is how Kalyani rates common security practices:
- Locking your computer (4/5): A vital physical defense-in-depth measure. You never know if your “one-minute” restroom break will turn into a longer coffee break, leaving you exposed to insider threats.
- Unrestricted access (0/5): Violating the principle of least privilege is a massive risk. If everyone has admin access, it only takes one compromised employee to expose the entire organization’s data.
- Security testing in DevOps: Despite arguments that it slows down development, testing is a crucial investment. Skipping it to move fast is a massive risk that can result in catastrophic financial and reputational damage if breached. Developers can leverage tools like ChatGPT to generate test cases, provided they act as responsible owners and verify the outputs.
