Why you should keep track of ur system security risks & how
👋 Hello technical folks ~
We believe most (if not, all) of you are using third-party resources in your application(s). In fact in today’s world, about 60–90% of the code base is actually made up of third-party code since it helps us to build whatever we want faster. This is why we need to monitor and take special care for all the third-party resources used, otherwise, the consequences will be unimaginable.
By now, we should already have (if you don’t, please do so!) security scans for all our third-party resources and fixed whatever risks we can. But, what happens to those risks that we can’t resolve at that point of time (due to no new library update)? Do we just forget about them and pray hard that they will magically disappear over time?
We recommend that your team keep a list of all unresolved risks and store this list in a centralised storage where it can be accessed easily by all members in the team (remember: security is everyone’s responsibility).
This list may contain these information:
- the library name and the affected version(s)
- what vulnerability does it contain and its impact
- the date that this risk is being flagged
- when you target to resolve it by (e.g. 1 month, 3 months, 6 months)
You may ask: “Do we need to track dev-dependencies?”
Well, it really depends on your team and system’s sensitivity since they don’t (and shouldn’t) go into the production environment. Same thing applies to test-dependencies and the library’s (internal) dev- or test-dependencies, and also if the library version your team is currently using is not the same as the affected version. However if you really want to be very very careful, then track all of them! There’s nothing stopping you from doing so, except that the Software Engineers (SWEs) may complain about having too many vulnerabilities. 😝
Once we’ve set up this security vulnerability/risk list, the next thing to do is to constantly review these risks. The review frequency should be discussed within and agreed on by everyone in the team, but we recommend reviewing on a weekly or bi-weekly basis. During each review session, the team should check if:
- there’s an update to the library,
- the vulnerable library is outdated (library hasn’t been updated for at least 1 year), and/or
- the author wants to fix it
For (1), it’s quite straightforward — team to update the library and test if anything breaks with this new library version. For (2), it’s either the team changes to another library that does the same things or clone down the code and self-maintain it. Same approach applies for (3), if the author doesn’t want to fix the risk. Just take note that no risk should stay forever in this list!
Now, for those of you whose system has got many different tracks or provides customisation of features to your customer, you may ask: “How can we best keep track of all these security vulnerabilities/risks for all our different tracks?”
If your system has got multiple tracks, it’s either you:
- have a master list of all security vulnerabilities/risks, or
- track them by different tracks
We hope this article has given you the answer(s) to your doubt(s) about whether you should be tracking your system’s/product’s security risks and how — at least track for those production-level vulnerabilities or findings which can’t be resolved at least 2 weeks before the release.
Oh! In case you’re still confused when a vulnerable library doesn’t have a fix, you can read our previous article here.
🧙🏼 Team Merlin 💛
Application security is not any individual’s problem but a shared responsibility.
