SCA: why you need it in your life
Let's start with the basics. What is SCA? Software Composition Analysis. Still none the wiser? In other words, what's in there besides the code you've written?
Scott Mitchell
You can't do it all yourself
There's very few cases where a project is built from the ground up without using someone else's code. That's just a fact. You haven't got time to rewrite frameworks for example, so you're just going to pull in a trusted package which would otherwise take you days, months or even years of work to write yourself. That's just how development works and use of the right open source packages are what helps to make most projects viable.
However, you should never just trust a third-party component even from the most reputable of vendors.
Open source components are just as susceptible to vulnerabilities as anything you or me write, more so in fact as they're far more readily available to any would-be attackers. So no matter how good your security setup is, if you're not checking the packages you're pulling in, you could be bang in trouble.
Trial and error
This is where SCA comes in. There are a lot of vendors out there and I won't bore you with a review of the best and worst because that's not what this is about. I'm going to talk specifically about Snyk in this case. Remember not all features will be available in each of the offerings you come across, but there are plenty of comparisons out there for you to peruse once you've finished this and realise you need something. You're going to want to think about IDE, CLI and especially CI/CD integration.
You may want to review a few offerings yourself and there's no point in taking all that time to embed them into a pipeline just to find out one of them doesn't include the functionality you'd expect. So why not start with the quickest option to set up? In this case, I'm referring to the CLI offering from Snyk. You'll need to set up a free account, but once done, you should be able to simply pull it in via your chosen package manager and have a play around.
If you're going to try a couple of different offerings, you can scan the same codebase with each and see how they differ in both functionality and results. Maybe one has config as code scanning capabilities but the other has better C++ support. Some are far more complex to target specific frameworks. It may be that one is dog slow and just not viable to run this as part of your CI pipeline checks.
It's all about what is most important to you and this will help give you a rough idea of what you're working with.
Seeing the benefits
Once you've narrowed your options down and are happy your chosen offering covers everything you need, it's time to get it into your pipeline. Now there are a couple of ways of doing this in Snyk. By far the easiest is to link directly to your code repository through the front end and simply import your repo for continuous monitoring. Once everything has been set up correctly, this will create webhooks in your source control, which will trigger each time a PR is created or updated. You can go one step further and stick a branch policy on your default branch, blocking any merges where an issue is raised within the scan. This is perfect for keeping vulnerable packages out of your codebase. Surely you've done your bit and all the 3rd party packages in your code are free of vulnerabilities, right? Not quite.
An ongoing commitment
Just because an exploit hasn't been found for a package now, doesn't mean it won't happen in the future. Attackers are constantly probing and prodding at stuff trying to find a vulnerability. Just look at Log4Shell. For 20 years it sat chugging away doing its thing without a care in the world. Then overnight BAM! it became the most hated package within the security community. Those of us with a decent SCA setup had to keep our phones on ice due to the number of notifications flooding in, but it gave us a head start to get on top of this before it was widely publicised and became a real issue. That's why continuous monitoring of your branches is a must. Not only on your development branch but more importantly, your releases. If you've got a vulnerable release out there in the wild, this gives you the jump to get a patch out quickly before your customers start asking questions... and they will
Terms and conditions apply
In addition to the automated security checks for PR's I described earlier in this article, Snyk also provides a licensing check which follows the same pattern. Now I'm not going to lie, I don't know all of the ins and outs of licenses but I'm fortunate enough to work for a great company with a Legal department that really know their shit. We worked together through all of the different license types within our license policy and simply marked the severities as High, Medium, Low or None. None means it's fine. Go ahead and use it without a care in the world. High means: My office NOW!
Depending on what you're creating, there are certain 3rd party packages you can use and others you simply can't. This is very much based on your situation so you're going to have to do a little reading up yourself on this one but start by taking a look at a couple of the packages you use, dig out their license documentation and 9 times out of 10 it will tell you whether or not you can distribute it as part of your project. Some may just provide a license type which means you'll have to do a bit of searching to see what that means. Snyk also gives you the capability to tag a custom message for each type of license meaning I was able to provide step-by-step instructions for the development team when they created a PR and stumbled over a bright red warning message telling them Snyk had picked up on an unsupported license. This allows the dev to speak with me and the rest of their team to find a suitable alternative that is supported by our licensing policies, which means no lawsuits and everyone gets to keep their jobs.
Putting it all together
Now to go full circle, we're going to go back to the CLI tool. It really is a great bit of kit and perfect for use in your build tools. But why do I need it you ask? I've got everything sewn up surely? Almost! The Snyk UI is fine for most things but it will currently only recognise a package and all of its dependencies if it exists in its own database*. That becomes an issue when you start including locally created packages for shared components like UI for example. Snyk will pick up 'MySharedUIPackage' but as it doesn't exist in their database, this is as far as it will go. You could have a couple of hundred dependencies in there which it's missed.
Now you could quite easily create a shared organisation within Snyk and import them all here for continuous monitoring. That'll work. But when it comes time to create a manual report with all of the outstanding security and licensing issues or just a full list of dependencies, you've got to look up your local packages and remember to pull a report for them as well and merge it into your original one. Who's got time for that? A far simpler way of doing this is to monitor during the build. This will capture each and every dependency it pulls in during the build as they're there in black and white. No reliance on a database. Depending on how your pipeline is set up, you also have the added benefit of capturing only those dependencies which will be shipped with the product. After all, who cares about vulnerabilities in unit tests? They're never going out the door so it doesn't matter what packages they use.
*Snyk has recognised this and has something on their roadmap to deal with it in the near future
What the hell are you on about?
I've tried to keep this as short as possible whilst touching on the main benefits of SCA that I've seen, but if you disagree, think there's anything I've missed or you'd like me to elaborate on, stick a message below and I'll get back to you
