[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Macro supply chains

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?


[1] Compromised npm packages lead to supply chain attack

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.