Open source has transformed the software world, tremendously reducing the cost of introducing new technology by enabling broad reuse across products and industries. However, organizations pulling their code from open source will often find themselves in scenarios where they have created a Frankensteined final artifact, with extremely fragmented origins.
This can cause problems when organizations fail to consider long-term support of the open-source libraries they rely on, and at worst can create security problems within their applications. The series of log4j vulnerabilities in late 2021 is a perfect example of this. Organizations must take time to carefully consider their approach to supply chain security to prepare for potential future security incidents, and to gain the full benefits of open source.
Open source isn’t exactly free
Code derived from multiple sources brings unique security challenges that organizations are not always equipped to handle – or even aware of. The supply chain can be incredibly complex, composed of a massive tree of open-source dependencies, all being updated on a regular basis. IT teams do not typically audit every line of code in their system when upstream open-source software is updated or changed. With a web of dependencies, constant changes, and lack of deep evaluations from IT teams, external security threats should be very much a concern, despite the origins from outside the organization.
Regardless of who is initially responsible for the bugs, organizations face liability when shipping software that includes vulnerability-ridden open-source code. Without processes in place to vet open-source inclusion and updates, organizations will continue to fall into the trap of utilizing open-source components without understanding the risks they are undertaking. Furthermore, as the software world continues to evolve, new technologies such as containerization will put a secure posture even further out of reach.
Upon publication of a vulnerability in an open-source project, organizations can be crushed with the burden of auditing updates to all relevant software updates within potentially tight deadlines. This can devastate developers’ productivity, as subject matter experts must choose to either audit thousands of lines of code, blindly accept the latest version of their dependencies, or both, risking introducing bugs in the process.
Despite the risk factors, there are ways for organizations to effectively secure and protect their usage of open-source code. With greater understanding of dependencies, and proper checks-and-balances in place to mitigate risks, teams can begin to feel secure in their open-source utilization and fully embrace its benefits.
Difference-makers to keeping open source secure
IT leaders should first and foremost establish policies that focus on threat and risk mitigation prior to beginning projects. Policies ensuring review and approval of new open-source dependencies, as well as regular updates of those dependencies are a must to reduce the risk of future disaster scenarios. This must be done with buy-in from development, of course – developers want to use the latest and greatest tech, and if they can’t use the best tool for the job they won’t be happy developers – but a minimal baseline policy can help frame the problem. Inventory and regular maintenance are key here because you can’t fix what you’re not aware of, and it’s vastly easier to update a dependency from last week’s release than it is to update from a release from the last decade.
Once these guidelines are in place, development should take the lead in implementing procedures to meet the policy requirements. This is where DevSecOps comes in: bringing a software development mindset to solving security problems can reduce cost and help break down barriers within organizations.
Firstly, teams need to understand what software is deployed in their environments, assuming they haven’t been documenting a bill-of-materials from the outset. This can be difficult because there are many layers of dependencies in a modern software stack. For one example, most container vulnerability scanners are limited to packages installed via the operating system package manager (e.g., apt or yum). By design, this misses many dependencies such as statically linked binaries, manually installed packages, programming language dependencies, and more.
Secondly, teams need to implement processes for keeping dependencies up to date. While this can be a strain on developer time and resources, this ongoing cost is assuredly much less than what would be required of teams during an unexpected breach – and more financially secure, as well.
Alternatively, organizations that do not have the developer resources to inventory dependencies and continuously monitor for vulnerabilities should reduce their security footprint by using platform-as-a-service (PaaS) products from cloud service providers. For example, purchasing a database-as-a-service (DBaaS) product rather than self-hosting a PostgreSQL cluster on a set of virtual machines can eliminate an organization’s responsibility for a very large stack of dependencies. This can allow teams to shift the focus away from mundane “undifferentiated heavy lifting” and toward innovation and business value.
Pulling the good out of the box and sealing away the bad
Organizations can – and should – take advantage of the rich rewards of the open-source community for excellent code and innovative solutions. But this must come with consideration and planning for the potential security risks at hand. IT leadership teams can significantly mitigate supply chain risk when they take appropriate steps to evaluate and guide inclusion of open-source dependencies. Preparing ahead of time can give peace of mind today, keep the risks at bay, and encourage developer innovation.
Credit: Source link
