Wow. Just WOW. Switching to SARIF instantly eliminated the need for a 30% custom code to support custom tools’ formats. The following scanners embed nice and well without any need for any extra code now: Snyk Code (This one uses SARIF everywhere, but I won’t tell anybody) Snyk Open Source Semgrep It worked like a charm. I guess I am a new SARIF supporter/champion now :) Scan Project major refactoring is still on the way, but that’s mostly the paid version stuff - the free scanner still works, and the image gets updated daily with new DependencyCheck vulnerability databases....

When I started working on the project, I researched SARIF, but it was only supported by a few security tool vendors and looked like a total nightmare to work with. But I am on a constant lookout to ensure that I am not reinventing the wheel, so I kept coming back to SARIF again and again, including experimental support, and read all the docs several times but kept declining the central role of the standard in what I am doing, even though it did look logical to use research by people that are way smarter than me....

It took me a while to update the blog, but if, for some reason, you are following the TSP (The Scan Project) progress here, it’s time to check out https://scanproject.io and https://docs.scanproject.io! Oh, and I totally revisited the decision about SARIF and DefectDojo support. Both are well-supported now :) In short, the free basic version of the project is available to all now. Semgrep Open Source, SonarLint, and Dependency Check are embedded and ready to use....

After significant code refactoring and lots of testing, I wanted to share the updated SonarQube screenshots that bring together vulnerabilities from different scanners, thanks to TSP. It’s the usual suspects: Snyk, SonarQube, Semgrep, and Veracode. All scanners are brought together at the same dashboard: Code review with vulnerabilities shown: Snyk in SonarQube: Semgrep is the only scanner so far to detect a pug vulnerability:

It’s a coincidence that I am publishing this post seven months after the last one. 2022 has been a very tough year, so the work on TSP progressed more slowly than I’d like to. But today, a working Veracode plugin is a critical milestone to share. Adding support for so-called “long-running” scans that have to be tracked asynchronously from the software delivery pipeline required a complete refactor of the MVP, but here we are....

Today is the day :) The first demo of “The (unnamed) Scan Project,” aka TSP, to the public. Currently, TSP consists of two parts: Server Command Line Interface (CLI) The server orchestrates different security and quality scanners (SAST, DAST, SCA, human test, QA, Lint, etc.). In addition, it tracks scan results and diffs between scans, containing logic that helps make decisions if the software is releasable at any point in time or any step of the pipeline....

Today, I worked on exporting issue reports in DefectDojo Generic Findings format and SARIF. Even though the POC worked as expected, what I experienced there made me rethink the priority for these items. Both formats are surprisingly complex and confusing, and I think they are doing the opposite of what this project (TSP) is trying to achieve, which is simplicity… With dozens of fields for each issue, I don’t think it’ll be easy for any downstream consumer, whether a machine or a human, to consume and process that complex data....

The first item I wanted to try was to bring all the scans together on the same page, and as always, the fastest way to do that is by using SonarQube’s support for 3rd party issues, so here’s what it looks like at the moment when TSP’s sonarqube export format is used. At this time, I am mostly testing using the vulnerable node app.

It’s been a while since I updated my blog - for the last three years, I have been working on a project that currently has no name, so I just call it “The Scan Project” (TSP). Now that it’s starting to work, I thought I should use this blog to post updates on the progress.