[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <EFD7F82B-BA85-43E6-BF5D-60A2EC54560E@unsafeword.org>
Date: Thu, 2 Apr 2020 11:19:11 -0700
From: Reed Black <reed@...afeword.org>
To: oss-security@...ts.openwall.com
Cc: Reed Black <reed@...afeword.org>
Subject: Re: Deficient engineering processes
> On Apr 1, 2020, at 4:42 PM, Jeffrey Walton <noloader@...il.com> wrote:
>
> [...]
>
> 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?
The answer will vary depending on the context - business vs hobbyist open source project, etc.
In business, one of the most common failings of a security program is in not making security defects visible at the executive level. Exec teams understand the liability of accruing security debt. Or if they don't, you need to demonstrate the business case by showing what happened to other companies where security failed.
You want to keep it high level. Make sure the exec team has a nice simple graph that shows any negative trends in open security issues over time. Personally, I like to make sure they see that once a quarter, the managerial teams see it at least monthly, and the engineering team sees the chart and a list of top or aging issues every week or two.
Once the exec team is on board and asking questions when things trend in the wrong direction, security issues become a liability for the managerial team, and therefore for the developers. As a liability, there should also be supporting resources approved from the exec team on down. If the security team is approachable and capable of providing guidance, the managerial and developer teams will begin asking for help in keeping the issue count low. This beats the security team having to fight for opportunities to insert itself.
Likewise, where you see risky development practices, you want to document these risks and make sure they are part of a risk assessment which the exec team sees once or twice each year. If you can articulate how deficient development practices create a business risk then again, the exec team should help create a demand for your assistance.
Outside of a business environment, the project leader will have to stand in for the exec team for any large open source project, whether it's a single leader or a small board. In order to avoid heroics and having to keep your fingers in everything, support needs to come from the top down.
Another common failing is in not creating a culture of security awareness. You probably read a fair bit of security news. Look for other projects which failed in a way which you could see your own project having failed. Drop links in chat or email and point to how a control your team has enacted would have prevented the incident. Or when you think it wouldn't have been prevented, ask "Is there anything we're doing that would have saved us from the same fate?" Anything that drags security away from the abstract and toward real world examples will help teams begin to understand the importance of good security practices. Ideally you create an appetite for correct solutions.
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.
