Date: Wed, 1 Apr 2020 19:42:38 -0400 From: Jeffrey Walton <noloader@...il.com> To: oss-security@...ts.openwall.com Subject: Deficient engineering processes Hi Everyone, Forgive my ignorance. I'm wondering how to handle deficient engineering processes, and I hope folks can share their thoughts. As I understand development lifecycles, there are 5 steps. The class I took in college taught them as SADIE: Survey, Analysis, Design, Implementation and Evaluation. I find a lot of projects have deficiencies in Implementation and Evaluation. Implementation is what most people think of with software. It is the actual code. Implementation problems are usually handled through a bug tracker. Implementation problems are usually instance problems. They are an instance of a bigger class of problems the project may be vulnerable to. Evaluation is usually not handled. Evaluation is the feedback cycle, and it is where postmortem analysis are supposed to be performed. The postmortem analysis should reveal why an instance problem occurred. Results from the analysis create changes, which are then fed back into the the process and the cycle repeats. For example, suppose a bug is reported for an undefined behavior sanitizer finding. The developer may (or may not) fix the finding. At the Evaluation phase, the postmortem should reveal why the bug surfaced and why the project did not detect the defect. The postmortem usually reveals a defective engineering process. For example, the Continuous Integration pipeline may not include a job to build with sanitizers. 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 know the GNU Coding Standards does not help here. It lacks the treatment of lifecycles and evaluation/feedback phase. It also lacks a recommendation for a continuous integration pipeline so many GNU projects do not use one. GNU Coding Standards also recommends "worse practices", like encouraging memory leaks which breaks testing. (The memory leaks are some of the worse advice I have seen in print. Attempts to get it corrected have fallen on deaf ears). Thanks in advance.
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.