fossa-action VS DependencyCheck

For us, there were a couple advantages. For context, I work at FOSSA (https://fossa.com/). Our core product solves software supply chain needs in enterprises (around licensing and security), and our core technology is around compiler, build, and source code analysis.

Off the top of my head, 3 advantages stood out:

1. First, if you're not going that far off the beaten low-level path, Haskell has incredible productivity benefits. Effect tracking has enormous benefits for testability and understandability. If you've ever been down a debugging rabbit hole shaped like "there's no way this logging call is sending that API request", then you might be pleasantly surprised to discover that you can statically guarantee that this doesn't occur in Haskell programs! Pattern matching, algebraic data types (sum types!), and typeclass derivation make it much easier to make it impossible to construct invalid representations of data. Other languages are finally picking this up, but their versions of pattern matching often have caveats for backwards-idiom-compatibility. And monads are a very powerful abstraction. It's like being able to write your own semantics for async-await (I've talked more about this before at https://lobste.rs/s/7cllte/monads_part_six_really_what_is_mo...).

2. Haskell was a good domain fit for us. One thing we build is the FOSSA CLI (https://github.com/fossas/fossa-cli/), which runs in customer CI pipelines to analyze their builds. It's a very compiler-shaped problem: shell out to some tools, do a lot of parsing, think very hard, and then spit out a JSON blob to send back to the API. Our first version of this was written in Go. At the time of development, writing correct, testable parsers in Go was like pulling teeth. We have a relatively small headcount-to-product-surface-area ratio, and our team was running up against the overhead of rewriting traverse in Go over and over again (that's a Haskell-flavored joke, but if you've ever been annoyed at writing yet another for-loop in Go, you get it). We decided to hack out a prototype in Haskell, and it turned out to be a good fit.

3. Lastly, the kind of people who wind up working at FOSSA and are interested in the code analysis bits tend to be the same kind of nerds who love Haskell. We had lots of people on our team who were chomping at the bit to try it, so we decided to try it out. I really can't understate how big of a productivity difference it makes when people are working with tools that they actually enjoy rather than are merely forcing themselves to use. It is night and day.

If you want to learn more, we also did an interview with Serokell on this topic (https://serokell.io/blog/haskell-in-production-fossa), and discussed it on an episode of our engineering podcast (https://fossa.com/blog/fossa-podcast-adopting-haskell/).

FOSSA scan - it is different from OWASP DependencyCheck and from Trivy scan. It is checking code for supply chain attacks on dependencies and for for license violations. For example, let's say, your project is using DependaBot tool for automatically upgrading dependencies. And you are using, I don't know, Gradle v7.6 (currently the latest version). A malicious person takes the source code of Gradle v7.6, adds some malicious stuff in it and publishes it in Maven Repository with version 7.7 . Don't know about DependaBot but some tools for sure will try to upgrade your 7.6 to 7.7 then. And often these upgrades are automated. If all the tests pass, end-to-end functionality tests pass, deployment passes, then the upgrade goes through. AND a vulnerability can be introduced to your system. FOSSA scan is for checking if the dependency supply chain is legitimate or fake. A downside is that a full scan will take many hours. So one of our teams is just testing it out, right now. It is not feasible to put a 4 hour blocker in our build pipelines. But with fast releases a vulnerability can be introduced already into the system.

Use Security Tools: To identify known vulnerabilities in your project's dependencies, you can utilize commands like npm audit or employ third-party security scanners such as DependencyCheck or Dependabot. These tools thoroughly analyze the dependency tree and offer actionable insights to assist you in resolving any identified vulnerabilities.

OWASP DependencyCheck - a really decent tool for scanning your project for vulnerable dependencies. It is actively developed and updated and up to date with the most latest vulnerabilities. Sometimes it can be a pain in the ass, though. Some security researchers and such find a vulnerability, publish it and the next day our CI/CD pipelines fail (the dependency check build step prevents the code from going to production). And not always there is a fix available. So, some vulnerabilities have to be ignored, temporarily. Also, to be able to ignore a vulnerability one has to do a fast risk assessment. And that will require from him to read about the vulnerability and decide if it is safe to be ignored or some different workaround must be found.

The ultimate guide somehow fails to mention the best CVE checker: https://github.com/jeremylong/DependencyCheck

We run https://github.com/jeremylong/DependencyCheck over our dependency tree regularly, via this Clojure wrapper: https://github.com/clj-holmes/clj-watson which tells us the dependency tree path to each item that has a CVE and also the version in which the CVE is addressed, if known.

We use OWASP dependency-check and pass reports to SonarQube.

From OWASP for those class of tools you could look into DependencyCheck and DependencyTrack

DependencyCheck is an open source tool that checks for vulnerabilities in dependencies used within a project. While it is a reactive tool, it's an important one since the code a developer writes is not the only code an application uses.

One more aspect to consider, although I know it is not the primary ask of the post, is to be sure and run something like dependency check on your repository. There are quite a few vulnerabilities being injected through the packaging process these days.