Each time, the culprit turned out to
be unused dependencies declared
by some library Sawzall did depend
on, combined with the fact that
Google’s build system eliminated
any manual effort needed to start using a new dependency. This kind of
error is the reason the Go language
makes importing an unused package
a compile-time error.
Upgrading is a natural time to revisit the decision to use a dependency
that’s changing. It’s also important
to periodically revisit any dependency that isn’t changing. Does it seem
plausible that there are no security
problems or other bugs to fix? Has the
project been abandoned? Maybe it’s
time to start planning to replace that
It’s also important to recheck the
security history of each dependency.
For example, Apache Struts disclosed
different major remote code execution
vulnerabilities in 2016, 2017, and 2018.
Even if you have a list of all the servers
that run it and update them promptly,
that track record might make you rethink using it at all.
Software reuse is finally here, and its
benefits should not be understated. It
has brought an enormously positive
transformation for software developers. Even so, we have accepted this
transformation without completely
thinking through the potential consequences. The old reasons for trusting
dependencies are becoming less valid
at exactly the same time there are more
dependencies than ever.
The kind of critical examination of
specific dependencies outlined in this
article is a significant amount of work
and remains the exception rather than
the rule. It’s unlikely that any develop-
ers actually make the effort to do this
for every possible new dependency. I
The Copay and Equifax attacks are
clear warnings of real problems in the
way software dependencies are con-
sumed today. We should not ignore
the warnings. Here are three broad
1. Recognize the problem. If nothing else, this article hopefully convinced you that there is a problem
here worth addressing. We need
many people to focus significant effort on solving it.
2. Establish best practices for today.
Best practices are needed for managing dependencies using what is available today. This means working out
processes that evaluate, reduce, and
track risk, from the original adoption
decision through production use. In
fact, just as some engineers specialize
in testing, others may need to specialize in managing dependencies.
3. Develop better dependency technology for tomorrow. Dependency
managers have essentially eliminated
the cost of downloading and installing a dependency. Future development efforts should focus on reducing
the cost of the kind of evaluation and
maintenance necessary to use a dependency. For example, package-dis-covery sites might work to find more
ways to allow developers to share
their findings. Build tools should, at
the least, make it easy to run a package’s own tests. More aggressively,
build tools and package-management
systems could also work together to
allow package authors to test new
changes against all public clients of
their APIs. Languages should also
provide easy ways to isolate a suspect
There is a lot of good software out
there. Let’s work together to find out
how to reuse it safely.
The Calculus of Service Availability
Ben Treynor, Mike Dahlin,
Vivek Rau, and Betsy Beyer
Tracking and Controlling
Silvia Esparrachiari, Tanya Reilly,
and Ashleigh Rentz
Thou Shalt Not Depend on Me
Tobias Lauinger, Abdelberi Chaabane,
and Christo B. Wilson
1. Baldwin, A. Details about the event-stream incident.
The npm Blog (Nov. 2018); https://bit.ly/2DRjySJ
2. Cox, R. Go & Versioning, 2018; https://research.swtch.
3. Cox, R. The principles of versioning in Go. GopherCon
Singapore (May 2018); https://www.youtube.com/
4. Cox, R. RE2: A principled approach to regular
expression matching. Google Open Source Blog (Mar.
5. Cox, R. Regular expression matching with a trigram
index or how Google Code Search worked. Swtch.com
(Jan. 2012); https://swtch.com/~rsc/regexp/regexp4.
6. Facebook. Infer: A tool to detect bugs in Java and C/
C++/Objective-C code before it ships; https://fbinfer.
7. GNU Project. GNU General Public License, version
1, 1989; https://www.gnu.org/licenses/old-licenses/
8. Go Project. Go 1 and the future of Go programs, 2013;
9. Google Open Source. Using third-party licenses;
10. Hipp, D. R. How SQLite is tested; https://www.sqlite.
11. Lacasse, N., Open-sourcing gVisor, a sandboxed
container runtime. Google Cloud (May 2018); http://
12. Langley, A. Chromium’s seccomp sandbox.
ImperialViolet (Aug. 2009); https://www.
13. National Institute of Standards and Technology.
National Vulnerability Database—Search and
14. Pike, R. Go Proverbs, 2015; https://go-proverbs.
15. Pike, R., Dorward, S., Griesemer, R. and Quinlan, S.
Interpreting the data: Parallel analysis with Sawzall.
Scientific Programming J. 13, 4 (2005), 277–298;
16. Potapenko, A. Testing Chromium: ThreadSanitizer v2,
a next-gen data race detector. Chromium Blog (Apr.
17. Potvin, R., Levenberg, J. Why Google stores billions of
lines of code in a single repository. Commun. ACM 59,
7 (July 2016), 78–87; https://doi.org/10.1145/2854146.
18. Reis, C. Multi-process architecture. Chromium Blog
(Sept. 2008); https://blog.chromium.org/2008/09/
19. SpotBugs: Find bugs in Java programs; https://
20. Thompson, K. Reflections on trusting trust. Commun.
ACM 27, 8 (Aug. 1984), 761–763; https://doi.
21. U.S. House of Representatives Committee on
Oversight and Government Reform. The Equifax Data
Breach, Majority Staff Report, 115th Congress (Dec.
22. Willis, N. A single Node of failure. LWN.net (Mar. 2016);
23. Winters, T. SD-8: Standard library compatibility, C++
standing document, 2018; http://bit.ly/2QNh T5k.
Russ Cox leads the development of the Go programming
language at Google, with a current focus on improving the
security and reliability of using software dependencies.
With Jeff Dean, he created Google Code Search. He
worked for many years on the Plan 9 from Bell Labs
Copyright held by author/owner.