Re: Deficient engineering processes

[Reed Black <reed () unsafeword org>]

> On Apr 1, 2020, at 4:42 PM, Jeffrey Walton <noloader () gmail 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.