We've learned nothing from the SolarWinds hack
Years after the SolarWinds breach, commenters argue that core structural problems in software security remain largely unaddressed, especially around the software supply chain. They highlight weak or abandoned mechanisms for verifying dependencies, deep dependence on centralized platforms like GitHub, and the economic incentives that favor rapid feature delivery over rigorous security. Proposed remedies range from better compartmentalization and capability-based systems to confidential computing and stronger regulatory or liability regimes, but many doubt these can be widely adopted without significant cultural and economic change.
Package Signing, Repos, and Dependency Trust
- Several comments criticize PyPI’s removal of PGP signatures and the broader lack of robust signing/verification in major package repositories.
- Some rely on distro packaging (.deb) and local mirrors instead of PyPI, noting better signature checking and patching of broken packages.
- Enterprise tools (e.g., JFrog/Sonatype-like) that hash and tag components across ecosystems are seen as useful stopgaps but not widely available from public repos.
- Heavy dependence on GitHub as the de facto backbone for CI, package sources, and code hosting is viewed as a systemic risk.
Scanning, Universal Tools, and Their Limits
- There is interest in services that analyze binaries or source for supply-chain attacks, but many doubt their effectiveness and scalability.
- Tools that detect “suspicious” package behavior (static/dynamic analysis) exist and are being actively developed.
- A universal package manager is widely seen as infeasible at scale.
Economics, Incentives, and Liability
- Commenters stress that organizations want “good enough” security at minimal cost; true hardening is seen as economically unattractive.
- Fines and regulatory pressure could help, but might entrench large vendors and harm small companies and open source.
- Some argue we should design systems to tolerate compromised software via compartmentalization and reduced blast radius, not assume all software can be made safe.
Capabilities, Sandboxing, and OS Design
- A standardized capability model is seen as ideal but politically and technically unlikely, and susceptible to abuse by vendors (e.g., redefining capabilities to protect business models).
- Others emphasize compartmentalization and redundancy, analogizing to safety-critical systems where single failures don’t doom the whole system.
- There is discussion of mobile permission models (iOS/Android), side-loading, and the trade-off between locked-down “secure” platforms and user freedom.
Supply Chain Security and Attestation
- Some propose hardened, isolated build systems and standardized metadata/attestation (e.g., in-toto, Witness) to track and verify supply-chain steps.
- Confidential computing with remote attestation is discussed as a way to prove artifacts were built from specific source with specific tools, even on compromised hosts.
- This shifts attacks toward compilers and build tools themselves, raising interest in memory-safe compilers and reproducible builds.
Operational Reality and Compliance
- Practitioners note that for advanced threats, prevention is limited; modern practice focuses on EDR, logging, SIEM, and detecting post-compromise behavior.
- Corporate networks are described as messy, with many legacy constraints and user-experience trade-offs.
- Security questionnaires and checkbox-style compliance are criticized as outdated and misaligned with cloud-native architectures, though there are attempts to streamline them.