Knowing your dependencies.
WHY IT MATTERS
You cannot meet obligations or respond to vulnerabilities in components you do not know you have.
WHAT TO MAINTAIN
An inventory of every open source component in your software.
WHAT TO RECORD FOR EACH
Name and version Licence Where it is used Why it was adopted Its own dependencies
WHY VERSION SPECIFICALLY
Vulnerabilities and licences are version-specific.
WHAT TO INCLUDE
Direct dependencies Everything they depend on
WHY INDIRECT ONES
Most components in a typical project were never chosen deliberately.
HOW TO BUILD IT
From the dependency files and tooling that reports them.
WHAT TO ESTABLISH
That the inventory is generated rather than maintained by hand.
WHY
Manual inventories are wrong within weeks.
WHAT TO ESTABLISH ABOUT UPDATES
That the inventory updates when dependencies change.
WHAT TO REVIEW
New components introduced Licence changes Components no longer maintained
WHY LICENCE CHANGES
Projects relicense, and an update can change your obligations.
WHAT TO ESTABLISH
Review before adopting any new component.
WHAT TO DEFINE
Which licences are acceptable Which require approval Which are prohibited
WHY IN ADVANCE
Discovering an unacceptable licence after building on it is expensive.
WHAT TO ESTABLISH
Who approves exceptions.
WHAT THE INVENTORY SUPPORTS
Vulnerability response Licence compliance Customer and buyer requests
WHY CUSTOMER REQUESTS
Larger customers increasingly ask what your software contains.
