[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87a73uek1o.fsf@hope.eyrie.org>
Date: Wed, 01 Apr 2020 18:46:43 -0700
From: Russ Allbery <eagle@...ie.org>
To: oss-security@...ts.openwall.com
Subject: Re: Deficient engineering processes
Jeffrey Walton <noloader@...il.com> writes:
> My question is, how to convince someone that following standard project
> management procedures is a good thing? How do we get them onboard with
> improving their engineering processes? Especially the evaluation phase,
> and leveraging a continuous integration pipeline to detect errors before
> they are released to users?
I would start by mentally dividing this into two cases: People who
consider security a top priority but don't know how to think about it
systematically, and people who don't currently have security as a focus.
The first group is the easy one, relatively speaking. There will be
disagreements about what are valid root causes (for instance, is it
correct to identify the choice of programming language as a root cause for
classes of vulnerabilities?), but even with those disagreements, there are
a wealth of tools available for essentially any language, and showing
people how to apply them better if they're already interested in
preventing security problems is straightforward, if sometimes
labor-intensive if the code base isn't very testable.
The harder problem is when security isn't a top priority. I don't think
you'll find many people who won't at least give lip service to security,
but that doesn't mean they're willing to invest in process to improve
security. This is particularly true in the broader world of small open
source projects without corporate sponsors. The maintainer may have only
a couple of hours a month to work on their project. If they spend that
time improving engineering process, that may be all of their available
time for six months, and in the interim no other improvements to the
software happen.
Worse, improved process usually means increased fixed overhead costs. A
CI pipeline will catch a lot of bugs and thus accelerate development in
some ways, but it will also break randomly and generate new problems that
have to be fixed (problems that are often much less fun than problems in
the main code). I personally spend substantial amounts of time fixing or
working around bugs in the CI pipeline for my personal projects. That
cuts into that couple of hours a month, possibly reducing it to zero.
In other words, I would argue that security for most open source projects
(by number, at least) is a resource problem, not a persuasion problem.
Their authors are not investing in engineering process improvement in
large part because they don't have time to both do that and to do the work
on their project that they find fun and that inspired them to release it
as open source in the first place.
That implies that the solution to look for isn't a winning persuasive
argument, but instead is a way to get the developer more resources, either
by somehow getting them more time to work on their project or by making
the cost of better engineering process substantially smaller than it is
now. GitHub's automated pull requests for dependencies with security
vulnerabilities is a good example of the latter.
--
Russ Allbery (eagle@...ie.org) <https://www.eyrie.org/~eagle/>
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
