Vulnerability management: know which ones matter and close them
Continuous scanning of images, dependencies and systems, prioritisation by real risk, verified patches and a monthly report you can use in audits and in your customers' security questionnaires.
Usual tools
- Wazuh
- WordPress
In short
Managing vulnerabilities means finding the ones that affect your platform, deciding which really matter and closing them with proof that they are closed. We continuously scan images, dependencies and systems with Trivy and Grype, prioritise by real risk rather than CVSS score alone, apply and verify the patches, keep the software inventory (SBOM) and deliver a monthly report.
- Languages
- Spanish, Catalan or English
- Response
- The next business day, during business hours
- Method
- In your account and your repository, in code and documented
What is included
- Continuous scanning with Trivy and Grype: images, dependencies and systems.
- Scanning in the CI/CD pipeline, before anything reaches production.
- Prioritisation by real risk, not just by CVSS score.
- Patches in an agreed window, verified with a fresh scan.
- Software inventory (SBOM) for every image and service.
- Justification and plan for every vulnerability left open.
- Monthly report for ISO 27001, ENS and customer questionnaires.
Who is it for?
For software companies that scan and are drowning in results, or that do not scan yet and are starting to need to prove that they do:
- The registry or pipeline scanner returns hundreds of vulnerabilities and nobody knows where to start.
- A customer sends you a security questionnaire asking how you manage vulnerabilities.
- You are preparing for ISO 27001 or ENS and need evidence month by month.
- Base images and systems have gone months without updates.
What do we do each month?
Scan
Continuously, container images, dependencies and systems with Trivy and Grype, including in the CI/CD pipeline.
Prioritise
By real risk: whether it is exposed to the internet, whether there is a known exploit and what data it could reach. Not just by CVSS score.
Patch
Base images, systems and platform components in an agreed window, with rollback; application dependencies, in a merge request for your team.
Verify
A fresh scan confirms that the vulnerability has really gone, not just that the patch was applied.
Report
Found, fixed and pending, each pending item with its justification and plan, and the software inventory (SBOM) kept up to date.
What do you get?
A monthly report you can understand without being an expert and that works as evidence as it stands:
Found and fixed
How many were detected, how many were closed and verified, and where they were.
Pending, with justification
Why each one is still open, what real risk it carries and when it will be closed.
Software inventory (SBOM)
Which components and versions each image and service contains.
It is the same vulnerability section that appears in the sample monthly report, with made-up data. You can use it for ISO 27001 or ENS audits and to answer the security questionnaires your customers send you.
How do you sign up?
It is included in SRE as a service. If you do not need the full service, it can be contracted separately from €300/month, depending on the number of images, services and environments (indicative prices, excl. VAT). If you want to know your starting point first, the reliability and security audit includes an initial review of images and dependencies.
Everything is done in your cloud account, your registry and your repository: the results and the inventory are yours.
Frequently asked questions
Why is the CVSS score not enough?
Because the score measures severity in the abstract, not on your platform. A critical vulnerability in a library that is not used, or in a service with no outside access, can wait; a medium one in something exposed to the internet with a known exploit cannot. We prioritise with that context and write it down.
Does it help with ISO 27001 or ENS?
Yes, as evidence: the monthly report shows what has been found, what has been fixed, what is still pending and why, which is what technical vulnerability management controls usually ask for. We are not a certification body.
Do you touch our application code?
We update base images, systems and platform components. When the fix lies in one of your application's dependencies, we prepare the change in a merge request and your team reviews it and validates it with its own tests before deploying it.
Tell us about your case
In a free 20-minute call we look at where you are and where to start. No commitment.
Reviewed on