Dependencies are a great tool for developers: They save time, which saves money and helps meet the need for speed when developing. But with great dependencies comes great responsibility because it’s easy to accumulate tech debt in the form of dependencies. What happens when you need to alter a line of code? Does it break your software? What is the cost of fixing a bug, updating dependencies, or adding a new module? Suddenly your software management starts to resemble the struggles of a monolithic architecture, where changing one small piece can break everything.
Software dependencies are like bricks, but flammable
Each module added to your software can be thought of like a brick: Small parts of a greater whole. But now imagine that those bricks are highly flammable. You have a significant chance of catastrophe with the tiniest of sparks.
That spark could be a single code change, deleted code like the LeftPad incident, a corrupted library, a missed patch, or patch that forces updates to all your other dependencies. There’s also the issue of security flaws – when a bug is found, the whole open source community is in the know, and that applies to hackers as well. Popular dependencies can quickly become targets as soon as the news of a patch is released. Another common risk of all third-party software and code are zero-day attacks, when a previously unknown vulnerability is exploited by hackers before a patch or update is applied.
Software dependency scanning: Your firetruck dispatch
Dependency scanners have risen in popularity and breadth in recent years, proving themselves useful tools for incident prevention. Scanners generally provide a list of all the dependencies within your code or app, along with a list of all the known vulnerabilities within each dependency. Scans can be done manually or automatically. Users can set up scans that run automatically within GitLab, which is helpful for code that isn’t updated often.
Dependency scanners can also be used to look for redundancies within projects that have been worked on or updated without a detailed changelog, or over a long period of time. Simplifying your dependencies will reduce the risk of a code change chain reaction, and will also reduce your attack surface.
Auto-remediation: The all-in-one fire prevention and firehose tool
Auto-remediation tools can find vulnerabilities within your code, evaluate the scope of any problems, and propose a solution. Developers can even set up auto-remediation tools to apply solutions under defined circumstances, shortening the time the vulnerability window is open to cyber assailants. Once that fix is automatically created, next it is tested. If it passes all the tests defined for your application, the fix is then deployed to production.
Auto-remediation tools can also help verify that changes made in dependency updates didn’t break any parts of your application – kind of like making sure you’ve turned off the stove before leaving the house.
Build your house by laying each brick with intention
Dependencies help simplify coding, but they add complexity when it comes to managing the bigger picture. So it is crucial to understand what dependencies you have, where you can simplify, and how your current and new dependencies will affect your software in the future. Take command of your dependencies with tools like dependency scanners and auto-remediation, and use that information and experience to build future software with efficiency and intention.
Cover photo by Grace Kadiman on Unsplash
