Curating Secure Software: The Art of Selecting Safe Dependencies

The talk treats software curation as the careful selection and upkeep of third-party dependencies, much as a museum vets what it displays. It opens with a recent case in which a widely used npm package was hijacked after its maintainer's account was taken over through an email-based two-factor reset. The speaker notes that most application code comes from external suppliers, often maintained by a small number of people, so a single compromise can reach many downstream applications.

The speaker argues that known vulnerabilities are only one risk to weigh. Other concerns include leaked secrets, license conflicts, such as a router vendor forced to release its source code, tampered or unsigned packages, and deep transitive dependencies that teams rarely see. Using a tangled string of holiday lights as a metaphor for a dependency tree, she explains how CVE, CVSS and CISA's KEV catalog differ, and how SBOM formats such as CycloneDX and SPDX help locate components. She also cites the short window, reportedly around 15 minutes, in which attackers begin scanning after a vulnerability is announced.

Her takeaways are practical. Before adopting a package, check its maintainer count, project health, community responsiveness and security practices. Keep an inventory of third-party components, scan regularly with free tools, and upgrade on a defined cadence, usually one or two versions behind the newest release rather than always adopting the latest. She also suggests a registry proxy that delays newly published versions.