Security testing
Pentest vs continuous vulnerability scanning: how they work together
A pentest (penetration test) is a time-boxed exercise in which skilled testers try to break into a system the way an attacker would. Continuous vulnerability scanning checks software automatically and repeatedly for known weaknesses. They answer different questions, so most security programmes need both.
Free plan, no card required.
What is a pentest?
NIST describes penetration testing as security testing in which evaluators mimic real-world attacks to find ways around the security features of an application, system or network. Testers chain small weaknesses together, probe business logic and judge what an attacker could actually achieve.
A pentest is scoped and authorised in writing, runs for a fixed period and ends with a report of findings, their impact and recommended fixes. Its result is a snapshot: it describes the system as it was during the test.
What is continuous vulnerability scanning?
NIST defines vulnerability scanning as a technique used to identify hosts, their attributes and associated vulnerabilities. Software composition analysis applies the same idea to code: it lists the open-source components a product contains and matches them against public advisories such as CVE records.
Scanning is continuous when it runs on every change and the inventory keeps being re-checked as new advisories are published. A component that was clean at release can become vulnerable months later without a single line of your code changing.
Pentest vs vulnerability scanning at a glance
The two methods differ in who does the work, what they find and how long the result stays true.
| Question | Penetration test | Continuous scanning |
|---|---|---|
| Who does it | Skilled people, often an external firm | Automated tools |
| What it finds | Exploitable chains, logic flaws and misconfigurations, with their real impact | Known vulnerabilities in components, exposed secrets and common misconfigurations |
| How often | Often yearly, and after significant changes | On every change and repeatedly between releases |
| Depth | Deep, on a defined scope | Broad, across every product and version |
| Result | A report at one point in time | An up-to-date list of findings and their status |
| Limits | Misses what changes after the test; costly to repeat | Does not prove exploitability or find new logic flaws |
Why you need both
The two cover each other's blind spots. A pentest finds what no scanner can: a broken authorisation check, an abusable workflow, a chain of minor issues that adds up to a breach. Scanning finds what a pentest cannot keep up with: the advisory published the week after the testers left, the dependency added in the next sprint, the firmware version shipped to a new customer.
Standards reflect this split. NIST SP 800-53 lists penetration testing (CA-8) and vulnerability monitoring and scanning (RA-5) as separate controls. The OWASP Web Security Testing Guide argues for a balanced approach: scanners have a place in a testing programme but cannot replace manual testing, and penetration testing should not be the only technique.
Scanning continuously also makes a pentest better value. When known vulnerabilities are already fixed, the testers spend their time on the problems only people can find.
How to combine them
A simple rhythm works for most product teams:
- Scan continuously from the start: every repository, container image and firmware version, re-checked as new advisories appear.
- Fix or document known vulnerabilities before a pentest, so the report focuses on what scanners cannot see.
- Commission a pentest before major releases, after significant architectural changes and as often as customers, insurers or regulators expect.
- Give testers your SBOM and the current list of open findings, so they can target the riskiest components.
- Feed pentest findings into the same tracking as scan findings, and re-scan after each fix.
Available in KROMSE today
KROMSE is not a penetration test and does not replace one. It covers the continuous scanning side: the URL scan checks what anyone can see from the internet, and KROMSE checks the code, dependencies, container images and firmware behind a product.
- Dependency checks against OSV.dev for lockfiles and manifests, including npm, Yarn, pnpm, Poetry, uv, pip, Go, Cargo, Maven, Gradle, Composer, Bundler and .NET.
- Secret detection at the scanned commit; secret values are redacted and never stored.
- Linux-based firmware images unpacked recursively, with packages checked against OSV.dev and the root file system checked for misconfigurations and embedded secrets.
- On paid plans, the latest SBOM of each source is re-checked against OSV.dev every 6 hours, and new matches appear as in-app notices.
- CISA KEV, FIRST EPSS, NVD and ENISA EUVD context on findings, with known-exploited vulnerabilities flagged.
Frequently asked questions
Is a vulnerability scan the same as a pentest?
No. A scan is automated and looks for known weaknesses. A pentest is led by people who try to exploit weaknesses, including ones no scanner knows about, and judge their impact. Testers often use scanners along the way, but a scan report is not a pentest report.
How often should you run a pentest?
There is no single interval. NIST SP 800-53 leaves the frequency to the organisation, and many organisations test yearly and after significant changes. Customers, insurers and sector rules often set a minimum.
Can continuous scanning replace a pentest?
No. Scanning cannot test business logic, chain weaknesses or show what an attacker could really achieve. It reduces the number of known issues a pentest has to spend time on, and it keeps watching after the test ends.
Do I need permission to pentest a system?
Yes. Testing a system without its owner's written authorisation can be a criminal offence; in the EU, Directive 2013/40/EU requires member states to punish illegal access to information systems. A pentest always starts with an agreed scope and written rules of engagement.
Does KROMSE do penetration testing?
No. KROMSE does not run penetration tests or full dynamic application testing (DAST). It checks code, dependencies, container images and Linux-based firmware for known vulnerabilities, secrets and misconfigurations, which complements a pentest run by qualified testers.