Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
We use Snyk as our open source dependency scanner. We currently scan for vulnerable libraries on every pull request and this causes overhead to our developers. What would be a good open source vulnerability scanning frequency? Should it be weekly, bi-weekly, monthly or continuous?
I am trying to suggest AppSec processes to my team and want to know about industry practices. It would also help if there is a best practices guide out there.
What is your vulnerability management policy?
Is it that developers cannot introduce any new vulnerabilities into their applications? If so, the 'overhead' scanning at PR is causing is irrelevant, as they will need to fix the vulnerabilities before they push to production and the sooner they find out about them, the better.
What are your timescales for patching vulnerabilities ? This will determine your scanning frequency. It is best practice to patch critical vulnerabilities within 48 hours of a patch being released, if that's the case then you will need to be able to detect critical vulnerabilities quickly and running a monthly scan will not meet your requirements.
The current focus on application security is to 'shift left' - so detecting vulnerabilities as early as you can in the development process. Scanning at PR is a great start and I would keep this security control, but you would want to make use of the IDE scanners Snyk provides and get developers in the habit of scanning for vulnerable dependencies before they even commit the code.
Developing applications without vulnerabilities isn't an overhead - it's a requirement.
I have never used Snyk, but I've used similar tools.
Running a scan on every pull request seems unnecessary unless that pull request is introducing a change to your dependencies. From my understanding of Snyk's documentation, Snyk scans your manifest files and uploads the dependencies and their versions. As Snyk's database of vulnerabilities is updated, it will alert you of any newly discovered or reported vulnerabilities in your dependencies. Unless you are adding, removing, or updating a dependency, you don't need to rescan.
The first question I would consider is how frequently you are changing your dependencies. If you are regularly changing your dependencies, then you may need to more regularly scan and upload the information from your manifest files to Snyk to make sure the reporting is accurate. However, if you don't change your dependencies often, then there may not be a need to scan as often. If the bottleneck is how long it takes to run a scan and upload the results to Snyk, I'm not sure that this action needs to be taken on every pull request.
If you really wanted the most accurate information, you could introduce some kind of logic to your build server to detect changes to your manifest files and execute a Snyk scan only on pull requests that introduce a change to your manifest file.
The more important thing, in my opinion, is how often you review the results from Snyk. It appears that Snyk does offer push notifications via email, Slack, and other tools when a dependency in your project has a vulnerability. This push notification could be useful to trigger your triage process to determine your exposure to the vulnerability and understand what you need to do to mitigate it.
If you've introduced Snyk to an existing project that has a lot of dependencies, you may be in a mode to play catch-up with updating to patch existing vulnerabilities. Rescanning on every pull request won't really help here, though, unless you're making lots of small pull requests to update each dependency and want Snyk to detect the change. I'm not sure that this is a good approach, though. I'd favor making sure that you have good automated test coverage, updating your dependencies, making any changes to your code to account for the new dependencies, and running both automated and manual testing to confirm that your changes are good. This is a good tactic if you have a large number of very out-of-date dependencies and are pulling major updates in - there could be a lot of work necessary to replace dependencies and it could be worthy of a release of its own.
Having a more robust process to control when dependencies are added and ensuring those dependencies are either free of vulnerabilities, the vulnerabilities are mitigated, or the vulnerability doesn't impact your system is also necessary. This doesn't necessarily require the use of Snyk. There are databases of open-source projects and their vulnerabilities - Snyk maintains one, as does Synopsis. Performing a lightweight vendor assessment to ensure that new dependencies do not introduce new vulnerabilities and you are only introducing dependencies that are well-maintained and offer an acceptable level of support is a good habit to get into.
After all of this, I would favor a nightly or weekly scan. On the more complex systems that I've worked on, running the full suite of all tests (from unit to system acceptance) takes a couple of hours. This testing happens on the development branch on a nightly basis. Integrating an open-source dependency scanner here can make sure that your reporting is always up-to-date, without introducing an extra step into every build. Developers can check in on the build every morning and triage failing tests as well as triage new vulnerabilities in dependencies. This can also be a good time to run static analysis on your code, and if you want to get very secure, deploy to a test environment and run dynamic vulnerability scanners.
