Category: Technology & Operations | Governance & Risk
Estimated read time: ~6 min
Imagine you’ve just taken over a small dev team, maybe four to eight engineers, and the product is moving fast. Features are shipping. Customers are happy. The backlog is three miles long and the CEO wants the next release by end of quarter.
Somewhere in the middle of all that momentum, someone — maybe your CISO, maybe a customer asking about your security posture, maybe your own gut — raises the question: are we building this thing securely?
You do a quick audit. Dependency scanning? Nope. Code review for security issues? Sort of. If the reviewer happens to notice something. Secrets in the repo? Possibly. OWASP Top 10 guidance baked into any workflow? Not really.
Now you’re holding two things at once: the pressure to keep delivering, and the dawning awareness that the foundation you’re building on has some cracks.
Here’s what I want you to know before you do anything else: you don’t have to fix it all at once. In fact, trying to do that will break your team’s trust and kill your delivery timeline. What you need is a phased approach. One that introduces security practices at the pace your team can actually absorb them.
Why “We’ll Add Security Later” Is a Trap
Before we get into the how, it’s worth naming the problem clearly. Security that gets bolted on after the fact is always more expensive than security that gets built in from the start. Not just in dollars but in time, rework, and the organizational pain of trying to unwind decisions that made sense in the moment but created exposure you didn’t see.
The OWASP Top 10 exists because the same categories of vulnerabilities have been showing up in web applications for over two decades. SQL injection. Broken authentication. Insecure deserialization. These aren’t exotic attack vectors, they’re the basics. And they keep showing up because development teams under pressure make predictable tradeoffs: ship the feature, clean up the code later.
“Later” has a way of never arriving.
This isn’t a criticism of your team. It’s a structural problem. And the only way to solve structural problems is with structural solutions meaning process changes that become habitual, not heroic one-time efforts.
Phase 1: Establish a Baseline Without Breaking the Build
Your first goal isn’t transformation. It’s awareness. You need to know what you’re working with before you can improve it.
Start with three things. First, get a dependency scanner in place. Tools like Dependabot, Snyk, or OWASP Dependency-Check can be integrated into your CI/CD pipeline with minimal friction. They won’t fix your code but they’ll tell you when you’re pulling in a library with a known vulnerability, which happens more often than most teams realize.
Second, do a one-time secrets audit. Secrets management is probably the fastest win available to a small team. If credentials, API keys, or tokens are living in your codebase, even in a private repo, you have exposure. Tools like Gitleaks or TruffleHog can scan your history. What you find might surprise you. Fix it, rotate anything that was exposed, and implement a pre-commit hook that prevents it from happening again.
Third, introduce a lightweight security checklist for pull requests. Not a 40-item audit. A short checklist. Five to eight questions: Does this endpoint validate input? Are there any new secrets introduced? Does this change affect authentication or authorization logic? Is user data being logged anywhere it shouldn’t be? Make it easy to use, and start using it on new code going forward.
This phase is about making security visible not mandatory perfection, but conscious attention. It changes the culture before it changes the code.
Phase 2: Build Security Into the Workflow
Once your team is comfortable with Phase 1 and it’s just part of how you work, you can start integrating security into the development process itself.
This is where OWASP guidance becomes actively useful. The OWASP Top 10 is a starting point, but the OWASP Application Security Verification Standard (ASVS) goes deeper — it gives you a tiered set of requirements mapped to application risk level. You don’t need to implement all of it. Pick the tier that fits your context and use it to define what “secure enough” actually means for your team.
Static Application Security Testing (SAST) tools can be integrated at this stage. Options like Semgrep, SonarQube, or CodeQL (built into GitHub) will analyze your code for security issues during the build process. Yes, they generate noise you’ll need to tune them. But they also catch things that human reviewers miss, especially under deadline pressure.
This is also when to start thinking about threat modeling. That phrase sounds academic, but the practice is practical: for each major feature or significant architectural change, spend thirty minutes asking “what could go wrong here?” Consider the inputs, the trust boundaries, and what a motivated attacker would try to do. Document the assumptions you’re making and the risks you’re accepting. It doesn’t need to be a formal document, even a few notes in your Confluence or Wiki page for that feature is better than nothing.
The goal of Phase 2 is to make security part of the definition of done, not an afterthought.
Phase 3: Mature Toward a True DevSecOps Culture
If Phase 1 is awareness and Phase 2 is integration, Phase 3 is ownership. This is where security stops being “the thing the security person worries about” and becomes something every developer on the team understands and takes responsibility for.
That requires training. Not a four-hour mandatory compliance course targeted, practical training on the specific vulnerabilities relevant to what your team builds. OWASP’s WebGoat is a free, hands-on learning environment where developers can practice exploiting and fixing real vulnerabilities. Running a team session through a few of those exercises does more for security awareness than any slide deck.
Dynamic Application Security Testing (DAST) fits here tools that probe your running application the way an attacker would, from the outside. Incorporating DAST into your pipeline, even just on a scheduled basis, gives you a different view than SAST does. The two approaches complement each other.
At this stage, you should also be thinking about a security champion model. Designate one person on the development team (someone with interest, not just the person with the most experience) as the security champion. They don’t need to be a security expert. Their job is to be the bridge between the dev team and security, stay current on emerging issues, and own the security review checklist. This distributes responsibility without creating a bottleneck.
What This Actually Looks Like in Practice
One thing I want to be honest about: this progression takes time. Phase 1 might take a quarter to feel natural. Phase 2 could take another two to three quarters, depending on how much resistance you encounter and how fast your team moves. Phase 3 is ongoing. It’s less a destination than a direction.
The pressure you’ll face is real. Stakeholders will push back on anything that adds steps to the development process. Your developers will grumble about false positives from scanners. Someone will argue that you don’t need this much overhead for a startup-stage product.
Your response to that isn’t to apologize it’s to show the math. The average cost of a data breach in a small to mid-size company is substantial and growing. The regulatory and customer trust implications of a breach that stems from basic, preventable vulnerabilities are worse. More to the point: remediating security debt at scale is always harder than building it in incrementally. You’re not slowing the team down. You’re preventing the kind of incident that stops the team entirely.
Lead with that framing, and most reasonable stakeholders come around.
Where to Start Tomorrow
If your team isn’t doing any of this yet, here’s your action item for this week: pick one thing from Phase 1 and implement it. Just one. Get a dependency scanner running in your pipeline, or run a secrets audit, or draft your first PR security checklist. Don’t announce a transformation start a practice.
Secure development isn’t about having the perfect process on day one. It’s about building habits that compound over time. You have to start somewhere, and somewhere is always better than nothing.
What’s the biggest obstacle you’re hitting when it comes to bringing security into a fast-moving dev team? Is it buy-in, tooling, time, or something else?
Clarity Through Experience is written in collaboration with Sophia, an AI assistant, and reflects the professional experience and perspective of Jose Ramirez.
Clarity Through Experience 
Leave a comment