The previous module closed by pointing at a word that appeared in all six of its lessons without ever being developed: verify. The risk register states that port 5432 is exposed, the control catalogue promises a monthly external scan that nobody has run (C-10, "planned") and risk R-07 talks about "forgotten services" without anyone knowing how many there are today. This lesson turns those assertions into measurements: you are going to learn to find what is exposed, decide what gets fixed first and prove that it was fixed, with zero-cost tools that fit within Nimbus's budget.

⚠️ Legal and authorisation warning — read it before running anything

Everything in this lesson is run exclusively against your own systems or with written, explicit and current authorisation.

• Scanning ports or launching a vulnerability scanner against someone else's machine without authorisation may constitute a criminal offence in Spain (arts. 197 bis and 264 of the Spanish Criminal Code). Curiosity is not a defence.
• In the cloud you must also comply with the provider's testing policy, and if the system is operated by a third party — the consultancy of A-19, the e-mail provider, the payment gateway — the authorisation comes from whoever operates it, not just from whoever contracts it.

All the material works on Nimbus's own ranges (10.20.0.0/16 in the office, 10.30.0.0/16 in the cloud) and its domain nimbusreservas.example. There are no exploits and no payloads: every finding comes with its fix. (The specific criminal interpretation depends on the case; before any test with an impact on third parties, seek legal advice.)

1. Vulnerability management as a continual process
2. The tool map: what each family finds
3. Network discovery with nmap
4. Vulnerability scanner: Greenbone/OpenVAS
5. Dependencies and containers: pip-audit and trivy
6. Static code analysis and secret scanning
7. Prioritisation: CVSS, EPSS, KEV and exposure
8. False positives, false negatives and validation
9. Integration into the cycle and process metrics
10. The vulnerability report

Almost every SME that "does vulnerability management" is in fact doing a one-off scan: once a year somebody runs a tool, exports a 300-page PDF and files it away. That does not reduce risk: it produces a document. The difference is a closed loop with verification.

Five rules separate the process from the theatre:

• Step 0 is not optional. A scan of 12 machines when you have 18 finds nothing on the other 6: coverage is the first metric, not the last.
• Several tools feed it, not one. No single family sees more than 30 % of the problem.
• Prioritising is not sorting by CVSS. It is the part that adds the most value and the one almost nobody does well (§7).
• A finding is closed when the rescan no longer finds it, not when somebody says they fixed it: that is the auditable evidence of 04-03. And whatever is not fixed becomes an exception with an expiry date (04-02), not a row that quietly ages.

A precision from 01-01: a version of OpenSSL with a CVE is a vulnerability; that service listening on the Internet is the exposure; the risk combines both with the criticality of the asset. A critical on a powered-off machine is not an emergency; a medium on the public API that reaches A-01 is.

The important column is "what it does not see". The IDOR that Nimbus fixed with WHERE tenant_id is found by none of these families: it is not an old version nor an obvious pattern, it is an authorisation flaw that requires understanding the business. That is why scanning is complemented with code review (05-05) and manual testing (05-03), and why no scanner can certify that a system is secure.

nmap answers the question Nimbus cannot answer: what is listening out there and in here?

Real output of the external scan:

The findings from 01-04, now measured and dated: 5432 reachable from the Internet confirms R-03 (only a password protects it); 6379 with Redis and no authentication is R-07; 8000 is the python -m http.server forgotten 94 days ago; and the contrast between 22/tcp open in preproduction and filtered in production proves that production does have a rule and preproduction does not. A-22 is today the weakest link at Nimbus.

Both points of view are needed and they measure different things. The external one (monthly, automated, control C-10) measures the surface an attacker on the Internet sees, that is, the exposure. The internal one (quarterly, from the bastion host and from the user VLAN) measures what is reachable by whoever is already inside or by a compromised laptop, and therefore reveals segmentation flaws and lateral movement: it is the one that would have discovered, before the incident, that the data zone was reachable from the administration network with no intermediate control (days 1-4 of 02-06).

nmap says what is there; the scanner says what is wrong with what is there. Greenbone Community Edition (formerly OpenVAS) is free and good enough for Nimbus. It only does two things, and it is best not to credit it with magic:

1. Compare versions against a vulnerability database. It is fast and it is the source of almost every false positive: distributions patch without bumping the visible number (backporting).
2. Active checks: it sends a request and observes the response — whether TLS 1.0 is accepted, whether a panel answers with default credentials. Slower and far more reliable.

The config id is the scan template (Full and fast balances coverage and time). A scanner that has to be launched by hand gets launched twice a year: either it is scheduled or it does not exist.

It finds far more because it stops guessing: without credentials it cannot see a vulnerable library that is not listening on any port, and most system vulnerabilities are exactly that. For Nimbus: an svc-scanner account without sudo, a dedicated Ed25519 key (03-06), a restricted source address and six-monthly rotation.

Three keys to reading it: QoD (Quality of Detection) is the most useful field and the most ignored — 99 % with an active check is a fact, 30 % from a banner is a hypothesis, so you start with high QoD and not with high CVSS; the 63 "Log" entries are not noise, they are inventory for 01-04; and a report with no findings only means that the scanner found nothing it knows how to look for: the IDOR in A-04 will never show up here.

80 % of the code the API runs was not written by Iván: it is dependencies. It is the fastest-growing surface and the cheapest to measure.

--requirement audits the project's pinned dependencies (without it you audit the machine) and --strict also fails when something could not be analysed: treating an "I don't know" as an "it's fine" is the root of false negatives.

The requests one is the relevant one: the API calls the payment gateway and the e-mail provider with that library. The jinja2 one only affects internal-panel templates. Same nominal severity, very different priority.

--severity HIGH,CRITICAL filters out the noise (a typical base image throws up 300 low findings, and including them guarantees that none of them get looked at); --ignore-unfixed hides whatever has no patch yet, and it is the most debatable option — Nimbus policy: use it in CI so the build is not blocked by something unresolvable, and do not use it in the monthly report; and --scanners vuln,secret,misconfig adds secrets in the layers and Dockerfile bad practices: three tools for the price of one.

A vulnerability present ≠ a vulnerability exploitable. perl-base is in the image because the Debian base drags it in, but the API never runs Perl: it is present and it is not reachable. Two concepts formalise this:

• Reachability: is there an execution path from Nimbus's code to the vulnerable function? Analysing it discards up to 70 % of the findings.
• VEX (Vulnerability Exploitability eXchange): a signed document in which you declare, per CVE and product, whether it affects you (affected, not_affected, fixed, under_investigation) and why.

Nimbus issues its VEX alongside the SBOM from 04-04: when a clinic asks about a famous CVE, the answer will be a document and not an emergency phone call. The response to a non-exploitable finding is not to ignore it, it is to document it. And the most effective way to reduce their number is to move to a minimal or distroless base image (05-07), which wipes out 80 % of these lines in one go.

-ll limits it to medium severity or above; --sarif produces the standard format GitHub displays in its security tab. A real finding in Nimbus's code:

SAST gets this right because verify=False is an unambiguous textual pattern, and it fails with the IDOR because knowing that a WHERE tenant_id is missing requires understanding the data model. Rule: it finds pattern errors, not reasoning errors. In 05-05 you will write your own semgrep rule that does detect Nimbus's specific pattern.

--log-opts="--all" is the critical option: without it, only the current tree is inspected; with it, every commit and branch is walked. A secret deleted the next day is still in the history and is still valid.

This is risk R-06 and the escalation on day 5 of 02-06. Fix in this order: (1) rotate the credential today — it has been compromised since 2024 and deleting the file does not invalidate it; this is the urgent step and the one almost everyone postpones; (2) move it to the secrets manager (03-06); (3) rewrite the history with git filter-repo, which is cosmetic compared with step 1; and (4) gitleaks as a pre-commit hook and as a blocking CI step (control C-12).

This is where the process earns its keep. A Nimbus scan produces ~180 findings and Lucía has 440 h/year for everything. Sorting by descending CVSS is the industry's most widespread mistake.

The environmental group is the one that turns a generic list into your list, and the only one nobody can calculate for you. Two external signals are added to it:

• EPSS (FIRST): the probability that a CVE will be exploited in the next 30 days, from 0 to 1, updated daily. More than 90 % of CVEs have an EPSS < 0.05; a minority concentrates almost all real-world exploitation.
• KEV (CISA): a catalogue of vulnerabilities with confirmed real-world exploitation. It is not a prediction, it is an observed fact; the list is short and consulting it is free.

Nimbus's operating rule: anything in KEV and reachable is treated as critical, whatever its CVSS. A 7.5 in KEV is more urgent than a 9.8 with an EPSS of 0.001.

Deadlines run from discovery, not from the publication of the CVE. And if a P1 misses its deadline it is not relabelled as P2: a signed exception is opened (04-02). Downgrading the priority so the dashboard stays green is the most common way of corrupting the process.

What the result reveals: REDIS-NO-AUTH has the highest CVSS (10.0) and falls to third place because it lives on an asset with criticality 2; CVE-2026-1044 scores 9.1 — more than 1010, at 7.5 — and comes last because it is not in KEV, it is not reachable and it does not affect a critical asset. Sorting by CVSS would have put Lucía to work for three days on the two least urgent vulnerabilities. An honest warning: A-22 having criticality 2 is the documented classification, and the inventory admits it is "to be reviewed". If preproduction holds a copy of real data, its criticality is 5 and the Redis goes straight to first place: reviewing that cell pays off better than any scan.

Validating a finding, in order of cost: (1) checking the real package version (dpkg -l | grep nginx) resolves 60 % of infrastructure false positives; (2) reading the distribution advisory (Ubuntu's USN, Debian's DSA), which says whether that version is already fixed; (3) checking reachability; (4) reproducing it non-destructively only if the doubt persists — verifying that a port responds or that a header is missing, never exploiting in production: that conversation belongs to 05-03; and (5) documenting the decision, valid or not, because a false positive closed without being recorded comes back every month and costs the same every time.

A scanner never replaces judgement. It does not know that A-01 holds records that reveal health information, nor that A-19 has permanent access, nor that preproduction may hold real data, nor can it find an authorisation flaw. It measures versions and configurations: the risk is set by the context, and the context is set by a person. That goes into the report's statement of limitations (§10).

The last one is the cheapest and the most underrated: comparing today's scan with yesterday's and flagging only what is new is what would have caught the http.server the same day, not 94 days later.

The design principle: block on what is actionable and report on what is not. A pipeline that breaks the build over findings nobody can fix ends up disabled within two weeks, and then it protects nothing. And the failure criterion is decided by Nimbus (ci/threshold.py), not by a tool that changes version: outsourcing it means handing over the governance of risk.

Structure of the monthly report: executive summary, scope and limitations, methodology and tool versions, prioritised findings, trend, closed and verified items, and a technical annex. The limitations are what honestly protects the reader: they say what was not scanned and what flaws these tools do not find.

The five elements that turn a finding into something actionable: reproducible evidence, business impact and not just technical impact, a concrete fix with an estimated effort, an explicit verification criterion and a named owner. The most frequent mistake is delivering the tool dump: 300 unprioritised pages that guarantee nothing gets fixed, because nobody knows where to start.

• Scanning once a year and calling it vulnerability management. The inventory changes every week; better monthly, automated and reviewed.
• Sorting by CVSS and starting at the top. Without exposure, EPSS/KEV and asset criticality you will spend your time on what matters least. It is the most expensive mistake in the lesson.
• Scanning without credentials "so as not to disturb anything". You lose between 70 and 85 % of the system findings; the authenticated scan is the single most cost-effective improvement.
• Forgetting preproduction. A-22 has more open ports today than production. The attacker does not tell environments apart: they tell doors apart.
• Blocking CI with impossible thresholds, or closing findings without verification. The first ends with the pipeline switched off; the second turns "closed" into "somebody said so". Watch the reopening rate.
• Tip: start with the diff. Before setting up Greenbone, automate a weekly external nmap that compares against the previous one and always keep the raw output with a date (-oA, JSON, SARIF): that is your historical series, and without a trend there is no conversation with management. Half an hour of work that would have avoided two of the four findings in 01-04.
• Tip: if you only remember one rule, make it this one. A CVE in KEV and exposed is dealt with today.

Lucía runs the first monthly external scan and gets:

1. What has to be found out about pruebas-2019 even before looking at the versions?
2. Order the actions for the first week, justifying the order with the criteria from §7.
3. What is missing from this scan for the process to be complete?

Rank them and assign a deadline according to the policy in §7, justifying each decision:

Identify at least five problems in Iván's proposal and explain how each one is fixed.

Exercise 1

(1) The first question is not technical, it is about inventory: what is pruebas-2019, who set it up, what data does it hold and is it still needed? That name suggests an environment from seven years ago that nobody maintains and that is neither in the inventory from 01-04 nor in the scope of any patching. If nobody knows, the fix is not to patch it: it is to switch it off once it is confirmed that nothing depends on it, keeping a backup. Switching off is the cheapest, fastest and most definitive fix there is, and the one least often considered.

(2) Order for the first week:

1. MySQL 3306 exposed (P0, 24 h). It is the R-03 pattern but worse: a database reachable from the Internet on a host unmaintained since 2019, with probably weak credentials. It is closed at the firewall today, before investigating anything.
2. Determine whether it holds real personal data (P0, in parallel). If it does and it has been exposed for years, it stops being a technical finding: it is a possible breach with GDPR obligations (06-03) and activation of the plan from 04-05.
3. Switch off the host (P1, 7 days) once it is confirmed that nothing depends on it. Apache 2.4.29 has accumulated years of CVEs: patching it means investing in something that must disappear.
4. Add it to the inventory and review the DNS, looking for more forgotten subdomains: the fact that it showed up in a scan and not in the inventory means coverage was not 100 %.

(3) What is missing: the scan only looks at the usual ports of names somebody remembered. Missing are subdomain enumeration from the DNS zone, a monthly -p- (the http.server on 8000 does not show up in --top-ports 1000), basic UDP scanning, internal scanning from the user VLAN and from the VPC to measure segmentation, and the layers nmap does not cover: authenticated scanner, SCA, SAST and cloud configuration. nmap is 15 % of the process.

Exercise 2

A cross-cutting observation: the first two require no patch, but a configuration change and a credential rotation, both free and a matter of minutes. The most urgent thing is almost never the most expensive.

Exercise 3

1. workflow_dispatch as the only trigger: it only runs by hand, which is to say almost never. Missing are pull_request, push to main and a schedule that catches new CVEs without code changes.
2. checkout without fetch-depth: 0: gitleaks only sees the last commit, so history secrets — Nimbus's real case — go unnoticed indefinitely.
3. trivy image nimbus/api:latest: it scans a tag that is not the image this change builds. One image is validated and a different one is deployed; you must build and scan by commit SHA.
4. --exit-code 1 without --severity: it blocks on any finding, including informational ones and those with no patch. It will be switched off within two weeks.
5. pip-audit without -r requirements.txt: it audits the runner's environment, not the project; it can pass green with vulnerable dependencies.
6. No result is published and there are no explicit permissions: without SARIF or artefacts there is no history, no trend and no evidence for 04-03, and the token operates with more permissions than it needs, against the least privilege of 01-03.

The corrected version is the one in section 9, with fetch-depth: 0, the three triggers, scoped permissions, an in-house threshold in ci/threshold.py, an image tagged by SHA and SARIF publication with if: always().

You have turned module 4's "verify" into a measurable process. You know that vulnerability management is a cycle — inventory, discover, prioritise, remediate, verify and report — and not an annual PDF, and that step 0 rules: without an inventory there is no coverage, and without coverage the other metrics lie. You know the map of the nine tool families and, above all, what none of them sees: Nimbus's IDOR does not show up in any scanner, because these tools detect pattern errors and not reasoning errors.

You can handle nmap option by option and you know why the external and the internal scan measure different things; with it you have rediscovered, with a date and evidence, the four findings from 01-04. You know what a vulnerability scanner really does, why the authenticated scan finds five to ten times more, and how to read a report starting with the QoD. With pip-audit and trivy you can distinguish a vulnerability present from a vulnerability exploitable, with reachability and the VEX document as the right way of saying "this does not affect us" without losing traceability. With semgrep, bandit and gitleaks you have closed the verify=False and found the PostgreSQL credential in the history, whose fix starts by rotating it and not by deleting the file. And you take away the part that separates a useful process from a useless spreadsheet: prioritising with base/temporal/environmental CVSS, EPSS as a probability and KEV as an observed fact, the P0-P4 deadline policy and a calculation that reorders the list until the 9.1 CVE ends up last; validating false positives in five steps; integrating it all into a pipeline that blocks on what is actionable and reports on the rest; and writing an actionable finding with evidence, business impact, an estimated fix, verification and an owner.

But notice the limit of everything above: this process finds badly closed doors; it does not see anyone walking through them. If tomorrow an attacker uses the consultancy's credential at 22:14, no scanner in this lesson will notice: the port is legitimately open and the credential is valid. That is the gap that left twenty days of silence in the incident of 02-06 and that the catalogue in 04-03 reflects with eight detective controls of which only two are implemented. In Monitoring and Detection Techniques (05-02) we finally build those controls: what to log, where to centralise it, how to write detections that fire on what matters and stay silent on what does not, and how to cut the attacker's dwell time from twenty days to one morning.