Developer Security - Software Composition Analysis
The differences between application security and developer security are simple enough in principle, but go significantly further as soon as you get past the surface. Many people in the cyber security community seem to place a great emphasis on the effectiveness of application security but in many cases, will completely negate the secondary portion of this which is securing the individual who is responsible for introducing security bugs to the software. I'm not saying that to be harsh, mistakes are a simple part of life and without the proper tooling and education it is very easy to continue to produce mistakes especially when greeted with constricted timelines and consistent budget crunch.
In general businesses will spend significant amounts of money to search source code for possible flaws, doing everything that they can to avoid dealing with the issues that create the flaws initially in software. Now it's important to note that I'm not saying that tools aren't useful, as a secondary check to make sure that issues that are getting into place are mediated in a timely fashion, is extremely helpful. But far too many businesses are relying on it as their single check against issues getting into the application.
Let's be that there are a set of tools that can easily help every developer make more secure code that is never included in any scanner. They're the parts of writing software that aren't interesting, and generally take more time than people are willing to spend. But in many cases, this is because businesses are looking at the return on investment from the security tooling because the security tooling allows them to prove on a piece of paper that they are focusing forward on cyber security.
So if you're interested in what you can do to protect your software from the developer side let's talk about some technologies that have absolutely nothing to do with software scanners, SAST, DAST, IAST, SCA or any other cyber security buzzword. Over the next couple of posts we will talk in depth about some of the tools that you can utilize to help you become a better more secure developer without ever touching any of these tools.
To kick this off we're going to talk about what you can do to help make your application more resilient against the aging of your software libraries. in the general world we refer to this as SCA or software composition analysis, I'm going to introduce it as a completely different topic. Making sure that you have proper security of your dependencies is what I will call basic software hygiene. there are a couple of things that we will want to talk about in this space, including the ability to keep these libraries up to date, make sure that you are appropriately adjusting for change, and preparations in the instance that there is something that is ground shaking that happens with the library.
if you want to get into a place where you never have to worry about dependencies ever again the number one tool that you can use to make that a reality, is use dependency injection for everything that you include in your code. The power of this is that whenever there a change, you can go through and make immediate revisions that carry across all your applications through an interface. By abstracting away your dependencies and the interfaces you have the best shot at being able to make the modifications to the libraries that you need when you need to make them.
The second portion of this equation is ensuring proper unit testing is in place for all those libraries. Unit testing is the first path that allows you to ensure that whenever you make changes to these libraries that things continue to function at the most basic level correctly it's also important to make sure that you have integration testing set U in such a way that it will allow you to automatically test these integrations. This will become even more important as we talk about the next section.
Integration testing becomes a huge benefit whenever you look at the process of doing automated updates to your dependencies on a per Sprint basis. The absolute best place that you can be in from a cyber security standpoint is if you are always updating the libraries that you're bringing into the project at the beginning of each Sprint. By doing this you will make sure that you always have the level of agility necessary to make a change if there's a zero day or some other issue arises. If you have full integration tests that are in place then you never have to worry about performing a nuget or npm upgrade, you already have a leg up on what the outcome is.
Lastly we're going to want to make sure that we go out to the location of the libraries that we are using in our applications, and we're going to want to make sure that we get a copy of the library for the worst case scenario. The first thing that you're going to want to do is go out to the location of the git repositories for each of the dependencies that you're working with, download them all to a folder below I will list this as: /git/Source. once you've done that you can utilize the script that I have included below and include it as part of a cron job to go and pull the latest version of the source code every day. This ensures that in the event where we have someone who has decided to make their software protestware or in the instance where they have been commandeered via ransomware, convert it to a closed license or just pull it from the internet, that you can easily rebuild the software and deploy A functional version for yourself.
By utilizing these techniques, you can almost completely remove the need for any form of SCA from your applications. Utilizing tooling that is already included as part of the framework and some good hygiene you can save yourself the money that would be spent on SCA tooling, and you are inherently in a better safer spot. Since this would be the goal of the SCA software in the end.
If you're interested in making cyber security part of your development practice and looking at it from a holistic standpoint, please do not hesitate to reach out to me. I would love to help you and your team produce safer, more secure software. As always thank you for reading our post and making your software more secure for a better world.