What can go wrong.
WHAT THE RISKS ARE
Licence non-compliance Vulnerabilities in dependencies Projects becoming unmaintained Licences changing Dependencies removed or compromised Support unavailable when needed Components that do not do what is assumed
WHY DEPENDENCY COMPROMISE DESERVES ATTENTION
Attackers target widely used components because compromise reaches everyone downstream.
WHAT TO ESTABLISH
Where components are obtained from Whether the source is authentic Whether versions are pinned
WHY PINNING VERSIONS
Automatically accepting the latest version accepts whatever it contains.
WHAT TO VERIFY
Integrity of what is downloaded, where the mechanism exists.
WHAT TO BE CAUTIOUS OF
Newly published packages with names similar to established ones Components with sudden changes of maintainer Dependencies added without review
WHAT TO ESTABLISH
Review before any new dependency is introduced.
WHAT TO DO ABOUT UNMAINTAINED PROJECTS
Assess whether to replace, fork or maintain it.
WHAT FORKING MEANS
Taking the code and maintaining your own version.
WHAT IT COSTS
Permanent maintenance responsibility.
WHEN IT IS JUSTIFIED
Where the component is critical and no alternative exists.
WHAT TO ESTABLISH BEFORE DEPENDING ON ANYTHING CRITICAL
What you would do if it stopped being maintained.
WHAT TO MAINTAIN
The ability to replace components.
HOW
Avoiding deep coupling to any single component.
WHY
It preserves the option.
WHAT TO REVIEW PERIODICALLY
The health of components you depend on.
