[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH8yC8=P-5i_0WT-AWSJ65JeY1C3BrB7p9e+4SCtH938H5ZqVA@mail.gmail.com>
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.
