Libraries
Incomplete article
More content to come as soon as possible. Want to contribute? Contact us on Slack (requires a Bouvet user account) or see the following issue on GitHub
The term libraries used in this article represents third-party libraries, in other words code imported into the project, running on our servers or in our build/release pipelines where the authors are external to the project.
The security risk associated with these libraries can be divided into two parts:
- They may contain known vulnerabilities (CVE) which can be exploited unless we act on them.
- They may contain malware allowing an attacker to access our system.
To protect against these threats there are several effective countermeasures we can implement:
- Use open source libraries or proprietary?
- Assess the license associated with a library:
- Financial cost of the license?
- Does the license permit commercial usage?
- "Copy-left"
- Assess the maturity and activity of the library. Will it exist in 5 years time, is it actively maintained?
- Update frequency. Is it an active and living library, or has development stagnated. Are there lots of open issues?
- Vulnerability history; does it have a history indicating that the authors don't know what they're doing?
- Download frequency; how popular is the library.
- Use lock-files to lock to a specific version (in the source code)
- NPM -> npm ci --ignore-scripts
- Protects you if a library is taken over by a new (and evil) owner!
- Keep libraries up to date
- Establish a procedure for this, avoid having it as ad-hoc work.
- Be aware of
- typosquatting, i.e. malicious libraries with naming similar to other and more legitimate libraries.
- dependency confusion. Attackers will create public libraries with the same name as libraries hosted on internal repositories, but with a higher version number.
- Run automatic dependency checks in the CI pipeline.