I know it might sound crazy, but always leading with the idea that I can be attacked now. Had helped me ask the question for the company what gap do i need to close
I like this statement
This also means continuously interrogating defenses the company is relying on with tools like continuous pentesting.
Attackers can be way more persistent but much more importantly the barrier to attacking is so low. We just have to accept that our company can and would be attacked .
And just like in life , focus on what you can control not what you can’t
Secure designs and resilience in the fact of adversity is a great start.
This reframes the diligence question for security startups too: does the product's efficacy depend on the attacker not having found something yet, or does it hold up after they have? A lot of "shift left" tooling is implicitly betting on obscurity - fewer eyes finding the misconfiguration before it matters. If recon cost is heading to zero, the vendors worth funding are the ones whose value doesn't erode the moment an attacker's agent stumbles onto the same map a scanner already had.
that question scales down a level too. when an investor's evaluating a five-person startup's security answer instead of a security vendor's product, it's the same test: is this evidence they did the work, or evidence nobody's looked yet. a founder who can actually answer instead of shrugging is giving you the same signal you're describing here, just earlier in the company's life
The point about AI facilitating scalability of attacks is well made and often lost in the FUD about novel attacks and frontier models, cheaper less glamorous models can do this too
The obscurity point held up in an odd way this summer. Wiz pointed an agent at one of Snowflake's public code projects and turned a five-day-old bug into a working key, no attacker required, which is your economics argument with a receipt. On the defender's information edge, most teams still can't say what a single service account reaches, so that edge stays on paper until somebody owns the asset map. Which of your three do teams actually fund first?
the service-account question is a good tell for how far down the size curve this goes. enterprise teams can't say what one account reaches. most five-person companies have never mapped it at all, because nobody's ever made them ask. to your question, the first bucket (reducing exposure) is probably the only one that's realistically fundable at that stage, telemetry correlation and incident response investment assume a scale and budget that doesn't exist yet. that ordering problem, what to actually do first when you have neither.
Reducing exposure first is right, and I’d narrow it further for a five-person shop. Pick the one account that would hurt most if it got used wrong, usually whatever billing or email runs on, and write down what it reaches. That’s an afternoon and no tooling, and it makes the next call obvious. Does that map ever get made at that size, or does it skip straight to alerts?
Mostly skips straight to alerts, or to nothing, since there's usually no alerting set up either. The map tends to only get made when something external forces the question: a data room request during fundraising, a vendor security questionnaire, or an actual incident. It's not that founders wouldn't do the afternoon exercise you're describing, it's that nothing tells them it's due until someone outside the company asks first.
Reducing exposure first, and not just because it's cheaper. It's also the only one of the three that ships as a product with a before and after number a board can see. Information advantage and resilience are both real but they're organizational investments that pay off as an absence, an incident that didn't happen or didn't spread, and that's a much harder thing to sell internally or to an investor. Founders pitching the other two buckets usually need a specific loss story from a design partner before anyone funds it, and that story takes a lot longer to collect than a scan result does.
The attacker-economics framing maps onto the other end of company size too, just inverted. Your three recommendations all assume an existing security function to build on, threat-informed defense, telemetry correlation, tested incident response. Early startupscompany doesn't have that scaffolding yet, and 'obscurity is dead' means something different for them: they were never using obscurity as a strategy, they were just genuinely too small to be worth an attacker's time. That protection is quietly disappearing too, for the exact same reason you describe, reconnaissance cost approaching zero. The prioritization problem you're describing at enterprise scale is the same shape of problem at four-person-company scale, just with a much smaller resource pool and no existing function to lean on.
That's the piece that changes for the smallest companies specifically. There's no budget line to reallocate, so reducing exposure first can't mean buying anything, it has to mean the free version, the same account mapping exercise Josh described, done by whoever's already in the room. The forcing function you flagged, a data room request or a security questionnaire, isn't just when the map gets made. At that size it's the only mechanism that exists to make anyone do it before an attacker does.
Right, and that's the uncomfortable part, the forcing function only exists because nothing internal replaces it. A founder has no natural moment where the account-mapping exercise becomes urgent on its own, so it waits for someone external to demand it. The honest fix isn't a cheaper version of enterprise tooling, it's something that manufactures that same urgency proactively instead of waiting for a data room to do it.
That's basically the bet behind the roadmap we built, give founders the forcing function before someone else hands them one.
The gap is credibility, not urgency. A data room request works as a forcing function because someone with leverage over the outcome is asking. A proactive tool making the same ask has to earn that same weight some other way, or a founder treats it like a checklist item and skips the parts that don't map to a specific screen. What actually gives the exercise teeth without waiting for an external ask, a real incident postmortem baked into the walkthrough, or something else?
Credibility over urgency is the sharper framing, and I don't think there's a clean answer to it.
The honest attempt is borrowed credibility rather than manufactured weight, each item tied to a specific incident pattern instead of an abstract best practice, so a founder isn't taking a checklist's word for it, they're seeing a concrete version of what goes wrong when it's skipped. That's real, but it's weaker than a person with leverage asking, and I'd rather say that plainly than pretend a walkthrough closes the gap.
A postmortem baked in might get closer, though even that risks becoming another thing to skim past if it's not tied to something the founder recognizes as their own situation.
That caveat is the whole ballgame. A postmortem only closes the gap if a founder can't wave it off as someone else's stack, which means it has to be specific enough to be checkable, a named vendor, a patch date, a mechanism, not a lesson. That's the reason I write the What Breaks pieces the way I do, a generic "here's what went wrong" reads like a best practice and gets skimmed the same way. The forcing function only bites when the founder recognizes their own dependency in the story.
That caveat is the whole ballgame. A postmortem only closes the gap if a founder can't wave it off as someone else's stack, which means it has to be specific enough to be checkable, a named vendor, a patch date, a mechanism, not a lesson. That's the reason I write the What Breaks pieces the way I do, a generic "here's what went wrong" reads like a best practice and gets skimmed the same way. The forcing function only bites when the founder recognizes their own dependency in the story.
"Named vendor, patch date, mechanism, not a lesson" is exactly the right bar, and it's a much higher one than most checklists even attempt, because it means you can't write it once and reuse it forever. A lesson stays evergreen. A checkable dependency goes stale the moment the vendor patches it or the founder migrates off it. That's probably the real tradeoff nobody wants to say out loud: the version specific enough to have teeth is also the version that requires constant upkeep to stay true, and the version that's easy to maintain is the one vague enough to skim past.
HIII I just wrote about two newly found Sharepoint bugs and how Microsoft has released a patch for just one so far. Please read and lmk your thoughts!! ❤️
I know it might sound crazy, but always leading with the idea that I can be attacked now. Had helped me ask the question for the company what gap do i need to close
I like this statement
This also means continuously interrogating defenses the company is relying on with tools like continuous pentesting.
Attackers can be way more persistent but much more importantly the barrier to attacking is so low. We just have to accept that our company can and would be attacked .
And just like in life , focus on what you can control not what you can’t
Secure designs and resilience in the fact of adversity is a great start.
This reframes the diligence question for security startups too: does the product's efficacy depend on the attacker not having found something yet, or does it hold up after they have? A lot of "shift left" tooling is implicitly betting on obscurity - fewer eyes finding the misconfiguration before it matters. If recon cost is heading to zero, the vendors worth funding are the ones whose value doesn't erode the moment an attacker's agent stumbles onto the same map a scanner already had.
that question scales down a level too. when an investor's evaluating a five-person startup's security answer instead of a security vendor's product, it's the same test: is this evidence they did the work, or evidence nobody's looked yet. a founder who can actually answer instead of shrugging is giving you the same signal you're describing here, just earlier in the company's life
The point about AI facilitating scalability of attacks is well made and often lost in the FUD about novel attacks and frontier models, cheaper less glamorous models can do this too
The obscurity point held up in an odd way this summer. Wiz pointed an agent at one of Snowflake's public code projects and turned a five-day-old bug into a working key, no attacker required, which is your economics argument with a receipt. On the defender's information edge, most teams still can't say what a single service account reaches, so that edge stays on paper until somebody owns the asset map. Which of your three do teams actually fund first?
the service-account question is a good tell for how far down the size curve this goes. enterprise teams can't say what one account reaches. most five-person companies have never mapped it at all, because nobody's ever made them ask. to your question, the first bucket (reducing exposure) is probably the only one that's realistically fundable at that stage, telemetry correlation and incident response investment assume a scale and budget that doesn't exist yet. that ordering problem, what to actually do first when you have neither.
Reducing exposure first is right, and I’d narrow it further for a five-person shop. Pick the one account that would hurt most if it got used wrong, usually whatever billing or email runs on, and write down what it reaches. That’s an afternoon and no tooling, and it makes the next call obvious. Does that map ever get made at that size, or does it skip straight to alerts?
Mostly skips straight to alerts, or to nothing, since there's usually no alerting set up either. The map tends to only get made when something external forces the question: a data room request during fundraising, a vendor security questionnaire, or an actual incident. It's not that founders wouldn't do the afternoon exercise you're describing, it's that nothing tells them it's due until someone outside the company asks first.
Reducing exposure first, and not just because it's cheaper. It's also the only one of the three that ships as a product with a before and after number a board can see. Information advantage and resilience are both real but they're organizational investments that pay off as an absence, an incident that didn't happen or didn't spread, and that's a much harder thing to sell internally or to an investor. Founders pitching the other two buckets usually need a specific loss story from a design partner before anyone funds it, and that story takes a lot longer to collect than a scan result does.
The attacker-economics framing maps onto the other end of company size too, just inverted. Your three recommendations all assume an existing security function to build on, threat-informed defense, telemetry correlation, tested incident response. Early startupscompany doesn't have that scaffolding yet, and 'obscurity is dead' means something different for them: they were never using obscurity as a strategy, they were just genuinely too small to be worth an attacker's time. That protection is quietly disappearing too, for the exact same reason you describe, reconnaissance cost approaching zero. The prioritization problem you're describing at enterprise scale is the same shape of problem at four-person-company scale, just with a much smaller resource pool and no existing function to lean on.
That's the piece that changes for the smallest companies specifically. There's no budget line to reallocate, so reducing exposure first can't mean buying anything, it has to mean the free version, the same account mapping exercise Josh described, done by whoever's already in the room. The forcing function you flagged, a data room request or a security questionnaire, isn't just when the map gets made. At that size it's the only mechanism that exists to make anyone do it before an attacker does.
Right, and that's the uncomfortable part, the forcing function only exists because nothing internal replaces it. A founder has no natural moment where the account-mapping exercise becomes urgent on its own, so it waits for someone external to demand it. The honest fix isn't a cheaper version of enterprise tooling, it's something that manufactures that same urgency proactively instead of waiting for a data room to do it.
That's basically the bet behind the roadmap we built, give founders the forcing function before someone else hands them one.
The gap is credibility, not urgency. A data room request works as a forcing function because someone with leverage over the outcome is asking. A proactive tool making the same ask has to earn that same weight some other way, or a founder treats it like a checklist item and skips the parts that don't map to a specific screen. What actually gives the exercise teeth without waiting for an external ask, a real incident postmortem baked into the walkthrough, or something else?
Credibility over urgency is the sharper framing, and I don't think there's a clean answer to it.
The honest attempt is borrowed credibility rather than manufactured weight, each item tied to a specific incident pattern instead of an abstract best practice, so a founder isn't taking a checklist's word for it, they're seeing a concrete version of what goes wrong when it's skipped. That's real, but it's weaker than a person with leverage asking, and I'd rather say that plainly than pretend a walkthrough closes the gap.
A postmortem baked in might get closer, though even that risks becoming another thing to skim past if it's not tied to something the founder recognizes as their own situation.
That caveat is the whole ballgame. A postmortem only closes the gap if a founder can't wave it off as someone else's stack, which means it has to be specific enough to be checkable, a named vendor, a patch date, a mechanism, not a lesson. That's the reason I write the What Breaks pieces the way I do, a generic "here's what went wrong" reads like a best practice and gets skimmed the same way. The forcing function only bites when the founder recognizes their own dependency in the story.
That caveat is the whole ballgame. A postmortem only closes the gap if a founder can't wave it off as someone else's stack, which means it has to be specific enough to be checkable, a named vendor, a patch date, a mechanism, not a lesson. That's the reason I write the What Breaks pieces the way I do, a generic "here's what went wrong" reads like a best practice and gets skimmed the same way. The forcing function only bites when the founder recognizes their own dependency in the story.
"Named vendor, patch date, mechanism, not a lesson" is exactly the right bar, and it's a much higher one than most checklists even attempt, because it means you can't write it once and reuse it forever. A lesson stays evergreen. A checkable dependency goes stale the moment the vendor patches it or the founder migrates off it. That's probably the real tradeoff nobody wants to say out loud: the version specific enough to have teeth is also the version that requires constant upkeep to stay true, and the version that's easy to maintain is the one vague enough to skim past.
Well said!
HIII I just wrote about two newly found Sharepoint bugs and how Microsoft has released a patch for just one so far. Please read and lmk your thoughts!! ❤️