High-Leverage Security Engineering Tasks
Focusing on scaling and engineering
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
I’ve intentionally made all of my posts free and without a paywall so that my content is more accessible. If you enjoy my content and would like to support me, please consider buying a paid subscription:
I was thinking about what to write this week when I came across an article on LinkedIn by Dade titled “High Leverage Security Decisions”. It’s a solid piece, especially for those who are the first/early security hire at a fast-growing startup. As someone who’s been that person more than once, a lot of it resonated, particularly the blend of strategic and tactical decisions that can define a company’s long-term security posture.
Dade ends with a thoughtful observation:
The keen observers among you will notice that, with the exception of security keys, much of this advice could be construed as generic IT or Infra advice.
I’m a strong believer that the largest security gains are largely not achieved through bolt-on processes, buying more tools, or spending the most money on security analysts. Those largest gains come from an obsession with operational excellence. With picking smart tools and then maximizing the value you get from them. With making small, iterative, strategic improvements in the systems you already have.
I couldn’t agree more with the overall message.
To back up a bit, I think a lot about scaling security impact. Like Dade, I don’t think that spending more money on tools and people will necessarily scale impact. I do think having a more engineering mentality toward security can.
That said, the piece was infrastructure- and IT-heavy. I want to offer a complementary perspective, focused more on high-leverage tasks in product and infrastructure security. These are things a security engineer can do, often without large teams or budgets, to make a disproportionate impact.
I’ve written before about why we need more engineers in security. Not just people who understand threats, but those who can design and build secure systems. Talent has always been limited in this field. Training helps in the long run, but we also need practical approaches that work in the near term.
Like Dade, I don’t believe that simply adding people or tools will scale security impact. But I do believe that adopting an engineering mindset will.
I’ve had a number of conversations with people who are trying to make early, smart security decisions at startups. They don’t want to fall too far behind or build up debt they can’t unwind later. This post is for them.
Start with everything in Dade’s article. Those items are essential. One thing I would add is that if your team struggles to roll out security keys, at least use WebAuthn to protect your most sensitive infrastructure. Services like AWS should not be accessible through weaker authentication. Yubico’s WebAuthn overview is a good resource if you’re new to the standard.
The ideas I’m sharing below build on top of that foundation. They reflect what I’ve found helpful, especially when joining startups where some engineering processes are already in place. The key is to understand those workflows, adapt to them, and then improve them without causing friction. Security improvements should come through steady progress, not massive overhauls.
Strategically choose tools that deliver strong value
Budgets are real constraints, especially at early-stage companies. That said, some tools offer such strong advantages that they are worth the investment or effort. I put them into two categories:
Tools that provide meaningful telemetry across the attacker lifecycle
Tools that every company needs but should not try to build
Examples of the first category include endpoint detection and response platforms like CrowdStrike, or email security systems like Material Security. These tools gather useful data and often include automated protection. CrowdStrike even offers a managed version, which helps when headcount is limited.
Vulnerability management tools like Semgrep or Snyk fall into the second group. They combine research with scanning, helping you find and prioritize issues without needing to build internal tools or staff a research team.
Open source tools can work, especially at scale, but the key idea is this: your team should spend time building the product, not building and maintaining basic security infrastructure.
Create a simple security review process
As engineering teams grow, it becomes harder to keep track of what is being built and shipped. A lightweight review process gives security a way to provide input before launch, rather than after something breaks.
This doesn’t have to be complex — having something simple is better than not having anything at all. Early on, you might:
Add a security question to your RFC template or pull request checklist
Track reviews in a shared document
Use Slack reminders or a basic form
Some teams are proactive in asking for help. Others don’t know what they don’t know. A review process ensures that the right questions get asked early and that security becomes part of the design conversation. It also positions security to plug into a more mature development process later on.
If you want some help, here’s a good resource on how to do security reviews.
Take ownership of cloud IAM
At my last two startups, I took over cloud identity and access management. Infrastructure teams were happy to delegate this. Their focus was on uptime and scaling, not access control.
Security is already expected to provide input on IAM. Owning it directly can be more efficient. But to do this well, you need to be fluent in infrastructure-as-code and cloud permission models. This is not just a technical task—it also builds trust with the infrastructure team and makes security part of the daily workflow.
A good foundation can be found in AWS’s IAM documentation.
Write code and use the product
I wrote an article a while back about how security can be a better team player with engineering. Security teams often get labeled as blockers. One reason is that they identify problems without offering clear solutions.
Writing code helps fix this. It builds credibility. It shows that security understands how the system works. It also allows the team to move from passive oversight to active contribution.
In my experience, security should directly own some solutions, but not all. A rough rule I follow is that security should lead about 30 percent of the time and support the other 70 percent. The goal is to be helpful, not overbearing.
Also, using the product builds business understanding. You’ll learn what customers care about, what data is valuable, and where tradeoffs exist. This helps when making risk decisions, especially in conversations with product and executive teams.
Here’s another article that I wrote on how to become a better security engineer, with some more suggestions on how to engage more with engineering and the product.
Help with engineering incidents
Startups don’t have large teams. Everyone works on incidents. Security should be part of this, too.
You’ll learn a lot about how the infrastructure behaves in production. You’ll see how teams communicate and solve problems. And you’ll build stronger connections with other engineers.
Understanding the engineering incident process also helps when designing your security incident response. If teams are already comfortable with certain tools or terminology, align with that. It reduces confusion when time matters most.
Conclusion
These are just a few examples of high-impact actions that security teams can take. The list isn’t exhaustive, but it reflects what’s been top of mind for me based on experience.
None of these approaches requires a large team or a big budget. What they do require is a clear understanding of how your systems work, the flexibility to adapt, and an engineering mindset that favors progress over perfection.
Even if your team doesn’t yet have all the skills mentioned here, they’re learnable. And investing in them can help your team move faster, solve harder problems, and deliver more value.
Security may never be perfect, but it should always be improving.