Service · Software development

Setting up vulnerability management.

Statutory reporting deadlines do not start when the incident occurs but the moment you become aware of it. An organisation that does not track its dependencies may discover something weeks later, and while it is formally on time, a gap may have existed for weeks. We set up the process to bring that moment forward.

Signal sourcesWeighting by impactRemediation deadlinesExceptions register
Arrange an introductory call View related work

Where it goes wrong in practice.

In four places, and rarely during the scan itself. First, at intake: your own systems are reviewed, but not the components the software relies on. Second, at weighting: a list is worked through from top to bottom based on a score set by someone else for a situation that is not yours. Third, at remediation: no deadline is agreed, so anything that does not feel urgent keeps getting postponed. And fourth, at non-remediation: whatever remains stays there without reason and without a date.

There is a fifth point that gets less attention: the moment of detection. Supervisors now look at it too, not only whether you reported in time but whether you could reasonably have known sooner that something was going on. That shifts the emphasis from handling incidents to spotting them, which is precisely the part most organisations have not set up anything for.

We don't build a scanner. Those already exist, and they are good. What we do is the process around them: connecting sources to what you actually use, a weighting that takes your own situation into account, deadlines that are achievable, and a register for what you deliberately leave in place. That builds on an up-to-date component inventory, ties into checks in the pipeline, and matches the reporting obligations under the Cyber Resilience Act and the Dutch Cybersecurity Act.

We set this up as a standalone engagement or as part of custom software development. If you are working towards certification, it aligns with ISO 27001-compliant development, and how we handle security ourselves is described in our information security policy.

Three types of engagement we take on here.

The sequence is almost always the same: find out, weigh up, agree. In the first conversation we establish where your biggest gap lies.

First engagement · fixed sprint budget

Connecting sources to what you actually use

Gather signals about the components your software depends on, not just the servers it runs on. That means linking to your component inventory and the container layer beneath it, using sources such as the national vulnerability database and open registries. The aim is to bring the moment of discovery forward, because that is where every statutory clock starts and where most uncontrolled time is lost.

Component inventoryContainer layerPublic sourcesSupplier signals
Mid-sized project · fixed sprint budget

Weighing what it means for you

A published severity score tells you about the vulnerability, not about your situation. A critical flaw in a component you ship but never call is less urgent than a moderate flaw at the heart of your login process. We combine three things: how severe the source rates it, whether it is being actively exploited, and where it sits in your landscape. You can only answer that last point if you know which components you use and for what purpose.

Severity from the sourceActive exploitationPlace in your landscapeAutomatic pre-sorting
Larger project · fixed sprint budget

Deadlines, register and reporting clock

A remediation deadline for each severity level that your team can genuinely meet, a register for anything you choose to leave in place – with the reason, the interim measure and a re-assessment date – and a link to your reporting obligations. We set it up so the information a notification requires comes from the same process: what was found, when we knew, which versions are affected, and which measure was taken.

Remediation deadlinesExceptions registerReporting clockReporting

What you have at the end of an engagement.

A process that runs without anyone needing to work through a list every morning, plus the record-keeping you need for an audit.

  • Connected signal sourcesSources that track your component inventory, your container layer and your purchased software, so that an alert reaches you without anyone having to go looking for it.
  • A weighting that accounts for your situationSeverity from the source, whether active exploitation is known, and where the component sits in your environment – together producing an order of priority that you can defend rather than simply adopt.
  • Remediation deadlines per severity levelAgreed with the people who carry them out, so the deadline is achievable and there is something to discuss if it is exceeded.
  • An exceptions registerFor each finding that remains: why it was not fixed, which interim measure has been taken, and when it will be reviewed again.
  • Linking to your reporting obligationsThe details a notification requires come from the same process, with the date of discovery recorded as the fixed reference point.
  • An intake route for external reportsA contact point and handling process for researchers who find something in your systems, aligned with your existing policy for this.

When this sounds familiar.

Four situations we keep seeing among organisations that approach us about this. Usually there is a trigger, and it turns out the process is missing more broadly.

The regulatory clock

You fall under a reporting obligation

The Cybersecurity Act or, for those placing a product on the market, the Cyber Resilience Act imposes short deadlines that start from the moment you become aware. Without a process that picks up signals early, that deadline cannot be met, however good your reporting procedure looks on paper.

The list keeps growing

Hundreds of findings are open

You scan, a list comes out, and that list gets longer every month. The problem is almost never the number but the absence of two things: a weighting that says what comes first, and a date for what remains in place.

Weeks between disclosure and discovery

You heard about it in the news

A vulnerability in a widely used component made headlines, and that was when the question arose for you whether you use it. That is too late, and it is preventable.

Audit or certification

The register is requested

In an audit, the first thing asked for is not the list of resolved findings but the register of what was deliberately left in place, with the justification. That is precisely what most organisations do not have.

How such a project runs.

1

Introduction and baseline

What is currently scanned, which sources feed in, and how long it took at the last major disclosure before a reasoned judgement was in place. That last question reveals more than an inventory of tools, and it is the benchmark for the rest of the programme.

2

Connecting sources

We connect the signals to what you actually use: your component inventory, the container layer, your purchased software and the suppliers who report their own issues. Where that inventory is missing, we start there, because without that list every notification becomes a search.

3

Setting up weighting

We combine severity, known exploitation and the place in your landscape into a pre-sort, and test that against the findings of the recent period: would this order have steered you in the right direction? That is a short experiment that prevents a lot of debate.

4

Agreeing deadlines and the register

Remediation deadlines per severity level, agreed with the people who carry them out and not only with those who decide. In addition, the register for what remains in place, with reason, interim measure and reassessment date. Without that date, every list keeps growing.

5

Linking and handing over the notification clock

Linking to your reporting obligations, rehearsing a realistic scenario once, and handing over to your team. Afterwards, an evaluation in which we measure the time to a reasoned judgement against the baseline.

Frequently asked questions about vulnerability management.

What security officers, IT managers and development teams ask us before they start on this.

We already scan. What does this add?
Scanning is the easiest part and is usually not where things go wrong. What is missing is a weighting that says what comes first, an agreed deadline within which something gets fixed, and a register for what remains in place. Without those three, scanning produces a list that grows every month and that nobody looks at any more. We set up the process so that the list becomes a working backlog.
Why is the published severity score not enough?
Because it tells you something about the vulnerability and nothing about your situation. The same score applies to a flaw in a component that is never invoked in your environment and to a flaw at the heart of your login process. The weighting that works combines three things: how serious it is according to the source, whether active exploitation is known, and where it sits in your environment. You can only answer that third point if you know which components you use and for what.
How do we prevent the list from continuing to grow?
Through two agreements. A remediation deadline for each severity level, so there is a point at which something must be finished, and a mandatory reason with a re-assessment date for anything that is not fixed. The second is the most important: without a date, a deliberate decision quietly slips into the category of things forgotten. We make both agreements with the people who carry them out, because a deadline that cannot be met gets ignored, and then you are further from home.
What belongs in the exceptions register?
Three things per finding: why it is not being remediated, which measure has been taken in the meantime, and when it will be reviewed again. This is not bureaucracy but the difference between a consciously accepted risk and something that has been forgotten. In an audit, this register is the first thing asked for, and it is also what you need yourself to keep the list manageable.
Does this also apply to software we have purchased?
For identifying issues, yes: you can track what becomes known about a product and which version you are running. Remediation then lies with your supplier, and that makes their remediation deadline something that belongs in your contract. We help formulate that clause and set up follow-up so that you can demonstrate when you reported the issue and what the supplier committed to. That is exactly what a regulator asks for if you were unable to remediate yourself.
How does this relate to our reporting obligations?
Both clocks, the one under the Cybersecurity Act and the one under the Cyber Resilience Act, start when you become aware of the issue. A process that actively collects signals and assesses them quickly is therefore not a side matter but the condition for meeting those deadlines. We set it up so that the information a report requires comes from the same process, so that at the busiest moment you do not have to gather data first.
Must we patch everything?
No, and that is one of the most useful outcomes of a good assessment. There are findings where updating carries more risk than leaving things as they are, and there are others where the supplier has not yet released a fix. Those belong in the register with an interim measure and a date. What does not work is doing nothing by default: that is the same outcome without the justification, and it is precisely what counts against you in an incident.
How quickly must we remediate?
You set that yourself for each severity level, and the right timeframe is the shortest one your team consistently meets. For findings known to be actively exploited, the bar sits considerably higher than for the rest, and that difference should be stated explicitly in your agreement. In regulated sectors, your supervisory framework sometimes provides direction; we treat that as a minimum rather than a target.
Do we need a separate product for this?
For managing findings across many projects and versions, a central system is useful, and there are both open-source and paid options. For smaller landscapes, you can manage with what you already have. We start with your existing tools and only recommend something new if it demonstrably solves a problem. We set out any recurring costs with you in advance.
Who should manage this on our side?
Someone with the mandate to set priorities, and that is usually not the same person who runs the scans. Assessing a finding is a trade-off between risk and effort, and that can only be made by someone who oversees the workload. In practice a combination works best: detection is automatic, the weighing is pre-sorted automatically, and the decision rests with a fixed person on a fixed rhythm.
What if someone outside finds something in our systems?
Then you want them to report it to you rather than publish it elsewhere, and for that you need a clear point of contact and a handling route. Appfront has its own policy for this, and we set up the same for you: where someone reports, what they can expect, and how such a report ends up in the same workload as everything else. Without that route, a report arrives at a general address and sits for days.

Talk to us about vulnerability management.

A half-hour introductory call, no obligation. Tell us how long it took the last time a major report came in before you knew whether it affected you, and we'll tell you where we would start, even if we don't end up working together.

Book an introductory callOr see our work

Edit content