Safely Using Third-Party Code in Applications
Third-party code is invaluable for helping applications function, but it can also be vulnerable to attacks. Learn how to use it safely and protect your app.
Open-source code isn’t a new concept. In the early age of software development — the 1950s and 1960s, almost all software resulted from academic and corporate collaborations and was ultimately released in the public domain. Even later, as software projects became much more lucrative and large companies attempted to monopolize both customers and software applications, many innovators still considered it an ethical responsibility to release their projects under an open-source license. Eventually, even many originally proprietary programs were later released as open-source.
The shift toward more openness recently received a big boost from a new law passed in Switzerland.
Switzerland’s landmark legislation, the “Federal Law on the Use of Electronic Means for the Fulfillment of Government Tasks” (EMBAG), mandates releasing government software as open-source code. This bold initiative is driven by the “public money, public code” mantra. It mandates that all public entities release any software developed by or for them as open-source code — unless they can’t due to third-party rights or security concerns.
Although EMBAG wasn’t passed until 2023, the law has its roots in a legal battle that began in 2011. This was when the Swiss Federal Supreme Court released its legal application, Open Justia, as open-source software. Its proprietary counterpart, Weblaw, sued — beginning legal and political battles over a decade until EMBAG was passed.
Now, government entities aren’t just allowed to publish OSS; they’re required to. Proponents of the law believe it will benefit everyone by eliminating single-source control over public sector software and ultimately reducing IT costs for all businesses.
EMBAG doesn’t stop at making source code public. It also mandates an open approach to government data, provided it’s not personal or security sensitive. The Swedish government hopes this open-by-default principle will increase transparency and collaboration, reuse, and code innovation within the public sector.
In general, the EU has been much more legislatively happy than the US regarding digital developments of all kinds. The EU passed the sweeping General Data Protection Regulation (GDPR) and just recently passed the world’s first artificial intelligence legislation, the AI Act.
Although they don’t necessarily apply to US-based businesses and citizens, the global nature of the internet means these laws have significantly influenced how US-based companies do business and, by extension, protect US citizens. While they haven’t inspired the same type of federal-level data protections in the US, there has been a rash of state-level legislation providing GDPR-type protections.
Extrapolating from data protection laws, we think you’ll likely see a similar “encouraged but not required” response from the federal government. The US government already hosts Code.gov, a platform for sharing open-source software, but that’s far from being a Swiss-style mandate.
The benefits of an open-source approach are apparent, which is why it was such a wildly popular model long before EMBAG. It encourages innovation and eliminates the need for developers to reinvent the wheel. Instead, developers can focus on building on top of existing applications rather than starting from the ground up. This dramatically shortens development time and cuts costs.
However, open source isn’t without its drawbacks. Because anyone can examine open-source code, it can also be exploited by anyone. Some of the biggest data breaches on record resulted from open-source vulnerabilities that weren’t patched—even after they were reported to databases such as OSV. Governments can only mandate OSS if they simultaneously commit to stepping up application security. If you’re releasing your code to the world—and presumably a slew of sophisticated malicious actors—it better be secure.
We expect to see the Swiss pass the requirement on to software suppliers through a mandatory software bill of materials (SBOM) and comprehensive OSS security. From the vendor’s perspective, since vendors have to do it for the Swiss, they may make it available to all customers using their software. We’ve seen this happen in other cases frequently, either as a way to add value or to avoid the extra expenses of separate options. The No Surprises Act went into effect in the medical industry in 2022. It required healthcare providers to give self-pay patients a “good faith estimate” of their expected costs. Because providers had to offer this to a segment of their customers, many began providing it to all of them since they already had the resources in place.
When the GDPR was passed, websites began giving all visitors a cookie consent popup because it was far easier than only providing one for traffic coming from the EU.
OSS tools and security will probably follow a similar pattern, with an SBOM becoming an industry standard. Of course, this will also be influenced by other cybersecurity legislative actions. The EU’s Digital Operational Resilience Act (DORA), though it only applies to financial institutions and their information and communications technology (ICT) providers, is also paving the way for this type of OSS security. These measures — understanding what’s in your codebase, testing throughout the development process, and implementing a patch management and incident response plan — are all elements of a mature security posture. They’ve been recommended best practices for years, but as we’ve seen with many tech advancements, the laws are slow to catch up.
At Kiuwan, we believe in taking a holistic, proactive approach to application security. If you consider security from the earliest stages of development, you’ll be ahead of the game, and your applications will be protected at multiple levels. Our Insights Open Source (SCA) gives you complete visibility into open-source and third-party components in your codebase, and our SAST tool continuously tests and automatically remediates open-source vulnerabilities and code flaws. Reach out today for a free demo.
