In December 2021, security teams around the world spent their holidays answering one question: do we use Log4j? The vulnerability known as Log4Shell sat in a small, ubiquitous Java logging library, and many organisations discovered they had no reliable way to tell which of their systems included it, often several layers deep inside other software. Then in early 2024, a backdoor was found in xz Utils, a compression library present in many Linux distributions, planted by a contributor who had spent a long time earning the trust of an overworked maintainer. It was caught, largely by luck, before it reached most stable releases. Together, those two episodes are the best short course in open source software security you will find: the code is everywhere, it is mostly excellent, and using it safely is a discipline rather than an assumption.
How much open source companies actually use
A typical modern application is mostly other people's code. A web app with a few dozen direct dependencies in its package.json or requirements file may pull in hundreds or thousands of transitive dependencies – the dependencies of your dependencies. Operating systems, databases, container images, programming language runtimes and frameworks are overwhelmingly open source.
That is a good thing. It is why a small team can build in months what once took years. But it means your security and legal position depend on code you did not write and probably have not read.
Open source licences: what you can and cannot do
Open source does not mean "no rules." Every project comes with a licence, and the licence decides your obligations. The main families:
| Licence type | Examples | Key obligation | Typical business impact |
|---|---|---|---|
| Permissive | MIT, BSD, Apache 2.0 | Keep copyright and licence notices; Apache 2.0 adds a patent grant and notice rules | Easy to use in commercial and proprietary products |
| Weak copyleft | LGPL, MPL 2.0 | Changes to the library itself must be shared under the same licence | Usually fine to link from proprietary code, with care |
| Strong copyleft | GPL v2, GPL v3 | If you distribute software that includes GPL code, the combined work must be offered under the GPL with source | Problematic for proprietary software you ship to customers |
| Network copyleft | AGPL v3 | GPL obligations also triggered by offering the software to users over a network | Significant for SaaS products |
Two nuances trip people up:
- Distribution matters. GPL obligations are triggered by distributing the software. Running GPL software internally or on your own servers usually does not trigger them; shipping it in an app, a device or an installer does. The AGPL was written precisely to close the "it only runs on our servers" gap.
- "Source-available" is not open source. Some vendors have moved projects to licences that restrict competing commercial use – HashiCorp's 2023 switch of Terraform to the Business Source License, which prompted the community fork OpenTofu, is a well-known example. Read the licence, not the marketing.
This is general information, not legal advice; for products where licensing is material, have counsel review your policy.
A workable licence policy
- Keep an allow list (typically MIT, BSD, Apache 2.0, ISC) that engineers can use without asking.
- Keep a review list (LGPL, MPL, GPL) that needs a quick check against how the product is distributed.
- Keep a deny list for your context – for many SaaS companies, AGPL in core services.
- Automate checks in CI so violations are caught on the pull request, not during due diligence for a funding round.
Software supply chain security: the real threats
The attacks on the open source supply chain fall into a few patterns:
- Known vulnerabilities in dependencies – the most common risk by far, and the most fixable. Log4Shell was this.
- Malicious packages – typosquatting (a package named to look like a popular one), dependency confusion (a public package with the same name as your internal one), and malware published to registries like npm and PyPI.
- Compromised maintainers or build systems – stolen credentials or, as in the xz case, a long-game social engineering attack.
- Abandoned projects – code that nobody patches any more.
Practices that hold up in reality
You cannot audit every line of every dependency. You can make attacks harder and response faster:
- Lock your dependencies. Commit lockfiles (package-lock.json, poetry.lock, Cargo.lock) so builds use exactly the versions you tested, and install from them in CI.
- Scan continuously. Dependabot, Renovate, Snyk, OSV-Scanner and similar tools flag known vulnerabilities and open update pull requests. Prioritise by whether the vulnerable code is actually reachable and exposed.
- Generate an SBOM. A software bill of materials, in a standard format such as SPDX or CycloneDX, lists every component in a build. When the next Log4Shell lands, an SBOM turns "do we use it?" from a two-week hunt into a query.
- Choose dependencies deliberately. Before adding a package, look at maintenance activity, number of maintainers, security policy, and signals such as the OpenSSF Scorecard. Ask whether you need a dependency at all for something a few lines of code would do.
- Pin and verify build inputs. Pin container base images and CI actions to specific digests or commits rather than floating tags.
- Use private registries or proxies for internal packages, and configure scopes so internal names cannot be hijacked from the public registry.
- Verify provenance where available. Signing tools such as Sigstore and frameworks like SLSA let you check that a package was built from the source it claims, by the pipeline it claims.
- Limit blast radius. Run services with least privilege and restrict outbound network access, so a compromised library cannot easily phone home.
When we build software at Mraviko, dependency scanning and lockfile-only installs are part of the project template from the first commit, because retrofitting them into a mature codebase is far harder.
Giving back is also security
Many critical projects are maintained by a handful of volunteers. The xz incident showed how burnout and isolation can become an attack vector. Companies that depend heavily on a project can fund maintainers, contribute fixes upstream rather than patching privately, and participate in foundations. It is not charity; it is maintenance of your own supply chain.
An open source safety checklist
- Licence policy with allow, review and deny lists, enforced in CI
- Lockfiles committed and used in every build
- Automated vulnerability scanning with a defined patch SLA
- SBOM generated for every release
- New dependencies reviewed for health and necessity
- Base images and CI actions pinned
- Internal package names protected
- A named owner for responding to supply-chain incidents
The bottom line
Open source is the foundation of almost all modern software, and the answer to its risks is not to avoid it but to manage it like any other supplier. Know what you use, know what the licences ask of you, keep it patched, and be able to answer "are we affected?" within hours. That is what open source software security looks like at companies that do it well.
