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.