Engineering notes, research, customer stories, and the occasional rant from the team building autonomous pentesting at Intrudify.
In a small company security work is spread across existing roles, and that holds until a task falls between two of them. A named owner and an honest time allocation are what stop an access review from belonging to nobody.
A questionnaire pulls in engineering, HR and legal at once, and the first one always costs the most. What makes the second one cheaper is a library of answers someone has already checked.
At 07:15 UTC on August 20, 2026, arrayref 0.3.10 appeared on crates.io, and within about 23 minutes, poisoned releases of internment 0.8.7 and append-only-vec 0.1.9 appeared. From the outside, everything looked like regular point releases of trusted packages.
Audit preparation fails in the same two places every time, and neither is the audit itself. Here is the order of work, and the evidence list to build against.
They are not competing versions of the same thing. One is an audit report about your controls; the other is a certificate saying you run a management system. That difference decides which your buyer will accept.
Every breached company with a clean audit report is the same story. Compliance measures whether you can demonstrate conformance; security measures whether an attacker gets in. Those come apart more often than anyone likes.
Most first risk assessments are a spreadsheet of generic threats with invented numbers. Auditors can tell. Here is the method that survives being asked "why this rating".
The CSF gets confused with every other NIST document, and with certification schemes it has nothing to do with. It is a voluntary structure for organising a security programme, and that is genuinely useful once you stop expecting a checklist.
Every honest answer to this starts with "it depends", so here is what it depends ON: the five factors that move the number, and the pricing models that hide it.
For a SaaS product, the highest-severity finding is almost always the same shape: one customer reaching another customer's data. That is not a generic web app test.
Most startup security checklists have two hundred items and no order, which makes them unusable. This one is ordered by what reduces the most risk per hour spent.
Not at incorporation, and not at Series B. The trigger is not company stage at all, which is why stage-based advice on this question is consistently unhelpful.
Every team tries to fix this with tuning and suppression rules. Those help at the margins. The real cause is tools that report what might be true instead of what they confirmed.
Sorting by CVSS score is the default and it is a poor strategy. Severity is not likelihood, and neither one knows anything about your application.
Most vulnerability management programmes fail at the same two places, and neither of them is the scanning. Here is the full cycle and where it actually breaks.
These get sold as near-equivalents at very different prices. They are not close. One produces a list of things to check; the other produces a list of things that happened.
Most descriptions of the pentest process are written for testers. This one is written for the person who has to schedule it, approve it, and explain the report to an engineering team.
Two different things get called "types of penetration testing": how much the tester knows, and what they are pointed at. Mixing them up is how scopes end up wrong.
A pentest without a named methodology is a tester following their instincts. The instincts might be excellent, but you cannot audit them, compare them, or tell what was skipped.
A plain explanation of what a penetration test is, what separates it from a vulnerability scan, who needs one, and what the report should actually give you.
These two get used interchangeably, and they are not the same thing. One describes who performs the test, the other describes what triggers it. You can have either without the other, and most teams do.
The useful comparison is not "which is better" but which constraint each one removes. Traditional testing is limited by human hours. AI-driven testing is limited by judgment. Those are different problems.
Most writing on this topic is either a sales pitch or a warning. The useful version is a ledger: what AI actually improves, what it makes worse, and where the honest boundary sits.
AI in security is not one thing. It shows up in at least five distinct places, doing different jobs with different track records. Here is the map, with an honest note on which parts are mature.
Two commercial AI pentesters had already been run over Fider and Photoview. We pointed Intrudify at the same targets, attacked them by hand, and compared what each engine actually catches.
Fable 5 genuinely raises your security baseline - but everything it does, it does by reading code. Why the running application is the half it can't reach, and how to cover the gap with dynamic testing.
All the security software in the world can't protect you from the biggest vulnerability of all: your people. A single click on a phishing email, a reused password, or a moment of carelessness can undo all your hard work.
Many founders and tech leaders think of Zero Trust as an enterprise-grade solution, too complex or costly for a lean startup. This couldn't be further from the truth.
In the interconnected world of modern software development, your security is only as strong as your weakest link - and that link is increasingly found in your supply chain.
This isn't about telling you not to use AI - the opportunity cost of ignoring it is far too high. This is a pragmatic guide on how to use AI efficiently and securely, balancing the immense potential with smart, cost-effective risk management.