Product Updates Q1 2022: Addressing the elephant in the room

Thinking about those topics, not as an individual but as a startup, is core to making sure-…

… Sorry, what’s that? What elephant in the room? Oh that’s right – we got acquired.

Acquisition

It is hard to start a Product Update blog post without addressing the fact that we were just acquired by CyberRes – a Micro Focus line of business… Many questions immediately arise, where the main one remains: “Will Debricked’s vision change?”.

The answer is straightforward. Our mission is still to help the world use great open source software, with minimal risk, in a convenient and non-intrusive way. The major change is our resources to realize the vision. It means that they are now larger – both in terms of funds, technology and competence.  

We are all really excited about the work we’ll be doing in the coming months and years.

Back to product updates

With the elephant back in its natural habitat, out of the room, let’s have a look at what has happened with Debricked’s product this quarter.

In short, our service has better performance, features are more stable in general and we’ve added some neat new additions to Open Source Select.

Queue time reduction

Queue time refers to the time a scan spends waiting to be picked up by an available worker in our cloud to be scanned. Naturally, this time should be as low as possible as it adds non-productive time to user’s pipelines, but as we’ve grown in the number of users, this time has gone up.

Significant changes went live by the end of February, which reduced the median queue time by 85% from the median queue time in December and by 96% from the median queue time in February, pre-fix.

Users can now expect a cool 6-second median queue time.

The old UI is no more

In creating new homes for the manual upload feature and the 2FA login screens, the last lingering views using the old UI are now gone.

We are very happy to reach this milestone and say farewell to the old relics of the past. Champagne has been popped and no tears shed.

Source Code-less Scans

We’ve supported Source Code-less scans for Gradle and Maven for a while. They were originally a way to give our users accurate scans without needing to share sourcecode with us. They still are, but there are more benefits of scanning using this method. 

In addition to removing the need to share source code, they also provide faster and more accurate results for some languages. More precisely this is applicable for languages, or rather package managers, that are not capable of generating a .lock file with a complete dependency tree.

For these reasons, we have worked to expand the languages and integration types covered by this method of scanning. In Q1 we have added support for:

• Golang
• Circle CI
• BuildKite

In addition to our existing support of:

• GitHub Actions
• GitLab

More languages and integrations will be added during Q2.

Another addition to supporting this scanning method is the ability to disable scans performed by the GitHub App, while still keeping the GitHub App for opening Fix Pull Requests. This means that you can, for example, run your Source Code-less scans in Circle CI – but still open Fix Pull Requests on GitHub using the GitHub App.

Fix Pull Requests using a Graph Database

Another huge milestone this quarter is the deployment of our Graph Database-based Fix Pull Requests for JavaScript. This is a foundational technology that we have been working on over the past year that will be a huge part of making it easier to solve vulnerabilities going forward.

Last year we released our first version of Fix Pull Requests. The new PRs still work according to the principles outlined in the launch blog post – but instead of relying on a brute force approach, we can now write queries in our Graph Database which contains all versions of all open source and their relations.

For our users this means 2 things:

• Fixes are more accurate
• Fixes take seconds instead of 10-20 minutes to generate

For Debricked, the nature of the solution means that we will be able to scale our fixes to more languages, way quicker than before, so stay tuned!

(A blog post diving deep into how the GraphDB works is on its way, so keep an eye out!)

Searching for non-packages in Select

It is now possible to search for all repos on GitHub, not just repos that exist as a package on a registry! This is now possible with two “search syntaxes”, the owner/name of the repository and pURL.

owner/name could be, facebook/react, arvos-dev/arvos, or any other owner and name of a repository. 

purl works as described in the readme in this project: https://github.com/package-url/purl-spec 

Examples: 

pkg:pypi/django

pkg:github/package-url/purl-spec

pkg:github/facebook/react

Security metric in Select

When evaluating an open source project, one vital aspect that should be taken into account is how secure the project is. Frequently, the evaluation is performed by finding out if the project has any outstanding known vulnerabilities that you need to worry about. While helpful, this approach has a major flaw: it’s highly subjective at times.

A project that has a few open vulnerabilities at the time of your evaluation might still be preferable to a project that currently has none. This is because you know that the first project effectively remediates the vulnerabilities, whereas the second one perhaps does not.

This is where the Security metric comes in. It tackles this subjectivity challenge by measuring how good a project is at working with vulnerabilities and security-related practices.

To streamline the process, the Security metric helps you answer some of the most significant questions such as how well do the maintainers respond to questions? What is the distribution over time of vulnerabilities? How fast are maintainers at discovering vulnerable code? Do contributors keep Pull Requests small? 

The right direction

Without getting sidetracked; when actually pondering the question, “are we headed in the right direction?”, my answer is most certainly yes. It hasn’t exactly been a bed of roses, but these past three months have also put us on a path toward the answer. The service is faster, more robust, and delivers more accurate results than ever before, while we continuously keep our eyes set on a dead-simple goal:

Help the world use great open source, with minimal risk, in a convenient and non-intrusive way.

And that’s what we’re going to do.