Synopsys, which owns both Coverity and Black Duck, wrote about software supply-chain integrity for a library with almost two million downloads per week:
"EventStream, a highly popular _javascript_ library, was compromised with the addition of a third-party dependency, flatmap-stream, containing encrypted malicious code. The attack targeted other Node.js libraries used in cryptocurrency wallets."
"Keep a bill of materials (BoM), a list of components and dependencies in your codebase. Just knowing what your code depends on will help make you aware of the third-party risks that you might be exposed to."
Are there existing best practices for tracking and maintaining macros which originated in other open-source communities, e.g. QEMU or Linux? Some Xen macros have diverged [2][3][4] from the versions used by other communities. Would such macros benefit from a documented relationship with upstream, e.g.
- "Ignore upstream changes"
- "Mirror upstream changes"
- "Review upstream changes"
For the latter case, build/test tooling could trigger manual macro review when a change is detected in an upstream dependency. Which other cases should be considered?
Rich
[1] Compromised npm packages lead to supply chain attack
