We love our bad habits. They wire our brains to keep us craving more of what they provide, whether that be a sugar high, a dopamine hit or some other immediate gratification that allows us to ignore potential risks.

When it comes to software development in general and software security in particular, a number of bad habits have become ingrained over the decades to where we may no longer even be aware of them. The best example may be downloading prebuilt binaries from open source repositories despite the fact that:

  • No details are provided about how the binary was built, or where its source code originated.
  • Your organization likely has no relationship with the author, and therefore needs to blindly trust them. Worse, most binaries include multiple dependencies, each of whose authors you’ll also need to trust. 
  • Precompiled binaries are difficult to scan in order to ensure they haven’t been compromised.

But installing prebuilt binaries is quick and easy, and gets us back to doing what we love, namely coding, while letting us avoid the pain associated with building binaries from source. 

Similarly, there are two other open source bad habits we continue to embrace:

  • Creating vulnerable codebases
    • As Sonatype has reported, 2.1B open source downloads with known vulnerabilities in 2023 could have been avoided because a better, fixed version was available – the exact same percentage as in 2022.
  • Working with outdated codebases
    • As Veracode continues to report, 79% of codebases are rarely updated once created.

Previously, software vendors could get away with effectively externalizing security risk to their customers, but that era is over:

  • Starting with SolarWinds, the US government has begun suing companies and employees for defrauding investors by misleading them about their cybersecurity capabilities.
  • Penn State University was sued in 2023 for allegedly failing to safeguard controlled unclassified information (CUI) and falsifying security compliance reports.
  • For public companies, SEC rules around cybersecurity that went into effect in December 2023 will have much greater repercussions than just disclosing whose data was compromised, including fines, censures, and more. 
    • The SEC has already brought a case against First American Financial Corporation (FAFC) for deficient disclosure controls and procedures related to cybersecurity risks.

But the US government is not alone: governments around the world are taking a similar approach. In other words, lacking proper security controls in 2024 will be a legal and economic threat to the survival of your business.

How to Update Vulnerable and Outdated Codebases 

The US government has been promoting a carrot approach to software security ever since President Biden’s Executive Order, which was issued in 2021. The incentive was access to lucrative US government agency contracts (DoE, DoD, DHS, etc). But even third-parties who aligned their products with the government’s security requirements could benefit by becoming suppliers to government contractors. 

However, the spectacular growth in online attacks over 2023 shows this approach has largely failed. Thus the growing emphasis on prosecution and the issuing of fines, instead.  

To avoid prosecution, software vendors will need to break their worst habits. Fortunately, all three are interrelated: by dedicating 10-20% of every development sprint to updating your  outdated codebase, you can also address vulnerabilities, and do it all in a secure manner. But this will require dependency automation, rather than trying to manually update your codebase, which is far too time and resource intensive. 

Automated dependency management is offered by a number of vendors, but is perhaps best exemplified by GitHub’s dependabot, which can: 

  • Notify you when it detects vulnerable components in your codebase
  • Substitute new versions of dependencies, where available
  • Allow you to automatically pull the update in order to upgrade your codebase. 

But as I’ve discussed elsewhere, developers are evenly divided over whether automated dependency management is helpful or not:

  • Sometimes everything just magically works.
  • Other times, updates cause dependency conflicts, pull in transitive dependencies that violate licensing or compliance rules, or simply just end up breaking the build, resulting in more work for overburdened teams.

And you still need to build any new binaries that get pulled in from source code in order to ensure security.

ActiveState takes a different approach:

  • A vulnerability status is provided BEFORE you build your codebase, allowing you to choose non-vulnerable versions of each dependency/transitive dependency instead.
  • ActiveState automatically resolves dependency conflicts, or else provides you with options to manually resolve them.
  • ActiveState automatically builds all dependencies from source code, including linked C libraries, for Windows, Linux and MacOS.

Over the next few weeks, I’ll provide details on how each of these capabilities can help you automate codebase upgrades and resolve vulnerabilities, providing you with a documentable cybersecurity process that can help your organization align with SEC guidelines, and avoid prosecution and fines.

Next Steps:

In the meantime, you can gain more context by watching our webinar, “Achieving the Impossible: 3 Steps to Minimize Risk & Reap the Benefits of Secured Open Source”