Expand on 'How does the Risk Workflow work for software producers"

[DinisCruz]

@koehntopp asked this great question on twitter which needs more than 140 chars to answer and should be covered in the book:

"...how do you use it if you produce software other people use, i.e. can you accept a risk on their behalf?."

https://twitter.com/koehntopp/status/792692846130241537

[DinisCruz]

Done https://github.com/DinisCruz/Book_SecDevOps_Risk_Workflow/blob/master/content/2.Risk-workflow/For-security-teams/Risk-workflow-for-software-vendors.md

[koehntopp]

Let me add some comments:

There are two scenarios that you're talking about in your text - open issues before and after release. Let me start with the "after" part.

When users or researchers report issues it turns into an "externally known" status which should increase the risk rating, and then it needs to be treated in an incident response process. For a cloud product this also means an increased risk as the exposure to attackers is higher. Other products need to take into account the cost of the fix - can customers easily apply the security update without interrupting business?

Before release, any issues detected influence what is at its core a business decision - so for an internal piece of code a business owner may accept an existing risk. In the case of software produced for customers, that would mean accepting a risk on the customers behalf, i.e. knowingly shipping a vulnerable product. This raises potential legal issues, which need to go into the risk. If there are possible technical or organizational mitigations for a risk they must be documented towards customers in order to protect them.

There are more details to this, need to come back to this maybe later...