A vulnerability is reported in a widely used component. The question is not whether it is serious, but whether it affects you. If you have an up-to-date SBOM, you can answer that in minutes; without one, you spend days making phone calls. We ensure the list is generated automatically with every build, so it cannot go out of date.
A Software Bill of Materials is a list of everything contained in your software: for each component, its name, version, origin and licence. That may sound limited, but it is exactly enough to answer the two questions that really matter: does this affect us, and may we use it this way? More important than the fields is the scope – a list covering only the components you chose yourself misses most of the picture, because the surprises lie in what came along with them.
The reason this is appearing everywhere now is twofold. The Cyber Resilience Act requires manufacturers to provide a machine-readable SBOM covering at least the top-level dependencies, and customers have started including it in their procurement terms. Those who have to put it together when the first request arrives lose days; those who generate it automatically can send a file and come across as stronger.
What we do is generate it in your build pipeline, in SPDX or CycloneDX, and connect it to the two applications that make it useful: licence checking and integration with vulnerability sources. That ties directly into vulnerability management and the requirements of the Cyber Resilience Act. We often do this as part of setting up DevSecOps, because it touches the same stage of the pipeline.
We handle this separately and as part of building custom software. For certification it aligns with ISO 27001-compliant development, and in an acquisition with the question of how much technical debt is in the code. Our information security policy describes how we handle this data ourselves.
Where you start depends on whether you need to demonstrate something, want to find something out, or both. In the first conversation we will tell you which option will deliver results fastest.
A list compiled by hand is out of date by the next release. That's not a matter of discipline but of pace. We therefore tie generation to the build itself, using tooling that suits your languages and package managers, in SPDX or CycloneDX. The list is produced as a by-product of something that already happens, and it cannot go stale without the build stopping. For every released version, the corresponding list is kept on file.
Most open-source licences impose few requirements, but a handful impose obligations that can extend to the code you build around them. You want to know that before you build, not after a client or buyer asks. We set up a check in the pipeline that blocks unwanted licences, and record deliberate exceptions in a register along with the reason.
The list only becomes useful once it is checked against what is already known. We integrate it with sources such as the national vulnerability database and open sources, and apply a weighting so that you don't treat every alert as equally urgent. With VEX you then record that a reported vulnerability does not affect you because the vulnerable function is never called in your environment, which saves your team and your customers a great deal of unnecessary worry.
A list that maintains itself, plus the two applications that make it more than a file in a folder.
Four reasons why organisations come to us for this. There is usually a direct trigger, and the benefits turn out to be broader.
You place software or a connected device on the European market and must be able to provide a machine-readable component overview. That is the immediate trigger, but the real benefit lies in the reporting deadline: without an overview, you will not meet the 24-hour window.
Standard terms for ICT procurement now stipulate that a supplier provides insight into the software and third parties it uses. Those who compile this by hand for each request lose time and credibility at the same time.
A vulnerability is reported in a widely used component, and a day goes into establishing whether you use it. This recurs several times a year, and each time ends with the same uncertainty.
In an acquisition, an investment round or a certification, you will be asked what the software contains and under which licences. An existing list shortens that investigation considerably and prevents surprises at the worst possible moment.
Which languages, package managers and build pipelines do you use, how many products and versions are there, and what is the trigger: a legal obligation, a request from a customer, or simply the insight itself? That determines which format and level of detail make sense.
We generate a first complete list and go through it with you. Almost invariably, the same things turn up: there are more components than anyone assumed, a handful haven't been updated in years, and there's a licence in the mix that nobody had checked for suitability. That isn't bad news; it's the outcome.
Generation runs as part of the pipeline, with storage for each released version. At the same time, we set up the licence policy and put the gate in place, initially as a warning and only blocking once the list is clean. Blocking on a pile of open findings only leads to the gate being switched off.
The list is continuously compared against what is known, with a weighting that takes into account where a component sits in your product. Where an alert doesn't affect you, we record that as a VEX statement so the same discussion doesn't come back every month.
A working session with your team, agreements on who reviews exceptions and how often, and an agreement on what happens when the gate stops something. Without that last agreement, a gate is circumvented within a month.
What development teams, product owners and security officers ask us before they get started.
A no-obligation introductory call of half an hour. Tell us what is running and what prompted the question, and we will say how we would approach it and what the first list will probably show, even if we ultimately don't work together.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
