Building a Vulnerability Management Program from Zero

I once ran a software startup where the entire security budget was my own time.

I was co-founder and CEO of a small company in Tallinn. We went through a startup incubator, we made a national competition final, and we built a mobile app with an international dev team I had recruited and was paying out of a very thin runway. There was no security engineer. There was no budget line called "security." There was me, and whatever I could make routine.

That constraint turned out to be a good teacher. Here is what I actually did, what was overkill, and what I would tell any small organization trying to start from zero.

Start with a policy, even though nobody wants to

I resisted writing an information security policy. It felt like paperwork for a company of our size. I wrote it anyway, from scratch, and I was wrong to resist.

The value was not the document. The value was that writing it forced decisions. Who can access production? What do we do when a library we depend on has a known flaw? How fast do we fix a critical bug versus a low one? Before the policy, the honest answer to all of these was "whatever seems right that day."

A policy for a small company should be short. Mine was too long at first, because I copied the shape of enterprise templates. Nobody read it. I cut it down to the decisions we actually needed, and then people used it. If a page does not change someone's behavior, delete the page.

You cannot manage what you have not listed

The unglamorous first step of vulnerability management is an inventory. Not a tool. A list.

For us that meant: the app itself, its backend, the third-party libraries in both, the cloud accounts, the laptops, and the handful of services we used to run the business. It fit in a spreadsheet. It still does for most small organizations.

The point of the list is that a vulnerability only matters if it lands on something you run. Without the inventory, every security advisory is either ignored or panicked over. With it, most advisories take thirty seconds to dismiss: not our stack, not our problem.

Put vulnerabilities in the same tracker as features

The single most important decision I made was refusing to build a separate "security process."

Vulnerabilities went into the same issue tracker the developers already lived in. Same board, same workflow, same standups. A dependency with a known flaw was a ticket. A finding from review was a ticket. Each one got a severity and a target timeframe, and the timeframes were honest — sized to what a small team could really do, not to what a compliance framework wished we could do.

I have since watched larger clients run vulnerability management out of a spreadsheet that only the security person opens. Those programs are dead on arrival. Engineers fix what is in their queue. If your findings are not in their queue, you do not have a program. You have a list of regrets.

Severity rules: simpler than you think

I initially built a scoring matrix with too many factors. It was overkill. Nobody could apply it consistently, including me.

SEVERITY — THREE QUESTIONS, THREE SPEEDS

   (1) reachable from the internet?
   (2) touches user data or credentials?      CRITICAL
   (3) known exploit / trivial to abuse?  -->    SOON
                                              BACKLOG

   more "yes" answers  ------------------->  the faster it moves

What survived was three questions. Is it reachable from the internet? Does it touch user data or credentials? Is there a known exploit or is it trivial to abuse? Answers to those three sorted everything into critical, soon, or backlog. A small team does not need more resolution than that, because a small team only has three speeds anyway.

Build the standards into how code gets written

We adopted secure development standards based on OWASP guidance and made them part of code review, not a separate gate. The checklist was short: how we handled input, how we handled authentication and sessions, how we stored anything sensitive, which libraries were allowed in.

Short mattered. A reviewer will apply five checks on every pull request. They will apply fifty checks on none of them.

I will write more about which of those checks earn their place — the categories that keep showing up have barely changed in years, and that pattern deserves its own piece.

Test before someone else does

Before we launched the app, I directed a penetration test against it. Attacking our own product before strangers could was the best money and time we spent on security.

Two things stayed with me. First, the findings clustered in well-known categories — the same ones our review checklist targeted, which told me the checklist was aimed at the right things and applied imperfectly. Second, the fixes were cheap because we found them pre-launch. The same findings discovered in production, with users and reputation attached, would have cost multiples more.

You do not need a big-name firm for this. You need someone competent who was not involved in building the thing, a defined scope, and a commitment to treat the findings as tickets like any others.

What I would do differently

Honestly: less process theater, earlier automation.

I spent early effort making documents look complete. I should have spent it wiring dependency checking into the build pipeline sooner, because that one automation caught more real issues than any document. I also let the severity matrix get clever before I let it get used. Simple and applied beats sophisticated and ignored, every time.

The sequence any small org can copy

If you are starting from zero, this is the order I would do it in now:

1. Write a two-page policy that records real decisions.
2. Build the asset and dependency inventory. Spreadsheet is fine.
3. Route every finding into the tracker engineers already use.
4. Adopt a three-question severity rule and honest fix timeframes.
5. Add a short, OWASP-based checklist to code review.
6. Automate dependency checking in the build.
7. Get an outside test before launch, and after any major change.

None of this requires a security hire. All of it requires that security work lives inside the work your team already does, instead of beside it. That is the whole trick. Everything I have built for clients since — as a consultant working with small and mid-sized organizations — has been a variation on that one idea.

The startup itself wound down in the ordinary course a couple of years in. The program outlived its usefulness to that company, but the method has paid for itself many times over since.

Cybersecurity in Plain Language: A Policymaker's Glossary →

← All writeups