About VioletBeacon

VioletBeacon Limited
Avondale, Auckland 1026
New Zealand
Phone: +64 22 645 9960
Contact us at sales@vltbcn.com

I started VioletBeacon in 2025 to solve a pervasive problem that I saw in the information security industry. Software engineers build their software using open source components, and those components will never be "perfect". There will be vulnerabilities, bugs and the like that the engineering teams need to be aware of so that they can update their components.

Now, I've seen roughly three main ways that engineering teams handle these updates:

1. They do it as early in the software development process as possible, keeping their libraries continuously up to date. The problem is that there are risks whenever you update your libraries. Did they introduce any new bugs? Are there any conflicts between transitive dependencies (such as the new library requires one version of a library, but another dependency requires a different incompatible version)? These risks often lead teams to give up on continual updates and fall back to approach #2.

2. The team does an all-at-once dependency update. This can get rid of some of the risks with #1, but if there is a critical vulnerability that needs to be fixed immediately, it breaks the engineering process unless the team has prepared for it. It also introduces a long delay before less critical vulnerabilities get fixed.

3. The final approach that I've seen teams use is to just never update their dependencies. This, obviously, is not a good solution and turns your company into a sitting duck for an attack.

So, how can we, collectively, improve this situation? I see a few options.

First, let's set some conditions and assumptions:

1. We are dealing with updating dependencies as a risk mitigation exercise. That means that we need a good and fast way to assess risk. If we can't assess the risk fully, good approximations are sufficient.
2. Engineering teams shouldn't have to be security experts (but this will have added value if they are). Likewise, security experts shouldn't have to be software engineers.
3. The data that is provided to software engineers must be actionable, and the application security systems must be design with their needs first.
4. Leadership, if desired by policy, must be made aware of the state of application security with available data, but not at the expense of the software engineers being able to do their job.
5. The best tool for each application security need (static application security testing [SAST], source composition analysis [SCA], interactive application security testing [IAST], dynamic application security testing [DAST], etc.) needs to be selected, again with software engineers being the overwhelming primary concern.

Now that we have those conditions to consider, how do we improve the process?

Let's focus on security engineers first. They need actionable information, in a way that integrates well with their work, and that allows them to fix the vulnerability and move on to the next task. My belief is that this is best done by running SCA as part of their regular development process. Before a PR is submitted, the engineer should look at the Dependency-Track report so that they are aware of what issues may exist and decide whether the change should be included in a this PR. On each pull request (PR), a SCA scan should be automatically run, and the report should be reviewed by the PR reviewers. Any increase in vulnerabilities should be rejected, by default, especially if they are high-risk vulnerabilities.

This brings up the question of how to assess risk. There are a few metrics that, while not perfect, are the best that we can do right now. And used together, they can give you some interesting insights. The first is to use the Exploit Prediction Scoring System (EPSS). The EPSS score gives a probability that a vulnerability will be exploited in the wild the next 30 days. The score is updated whenever new information comes out, such as a known exploit or proof of concept.

The Common Vulnerability Scoring System (CVSS) is another risk assessment score that looks at the severity of a vulnerability. Using the EPSS and the CVSS together, based on research done by FIRST, provides an valuable way to assess the severity and probability so that you can prioritize fixing the highest risk vulnerabilities first.

Now that the highest priority vulnerabilities have been identified, the engineers need to know the difficulty of updating the dependency. If a sufficient test suite is in place, the dependencies could be updated and you should have a high confidence that no issues have been introduced. But what if that test suite doesn't exist? The engineers would look at documentation for the library to see if any issues are raised, look at the changes in the components to see if they are likely to have any effect, or apply the update and do a (manual) smoke test on the application. Here is something that don't yet exist in the market, but would be very interesting: Include the relevant change in the vulnerability report to help the software engineers assess the difficulty in applying the update; automated smoke tests as part of the vulnerability report; using DAST tools to determine if the affected code in the vulnerability is actually used in the application (ideally in automated unit or integration testing).

For changes that require significant amounts of work, there really isn't any way around doing them. Here, using the EPSS and CVSS scores can help to determine whether it is something that needs to be done immediately, or can be delayed. This is ultimately a decision that the organisation needs to make in the context of their larger risk management process.

At the end of it all, Software Engineers are usually doing this work, and the process needs to focus on them and their needs. That is why we have selected Managed Dependency-Track as our first product. We believe that it provides the most benefit in the least amount of time, is affordable for companies of all sizes, avoids vendor lock-in, and can be easily integrated into the workflow of software engineering teams. I hope to have you join us on this journey.

Sincerely,

Kris Hardy, Founder/CEO/Security Architect

LinkedIn