[Owasp-topten] A9 - Disputed Risk

Dave Wichers dave.wichers at owasp.org
Mon May 20 16:59:29 UTC 2013


Your analysis, in my opinion, is seriously flawed. If my app, which owns and
processes my data, is compromised due to a flaw in a component that I chose
to use then it's my loss. I may try to place blame on the component provider
but since most such providers are open source, there certainly is no
financial benefit from trying to shift such blame. There 'might' be some
slight PR benefit to trying to shift blame, but I think most people would
laugh you out of the room if you tried to do so.  It's your app, so you are
ultimately responsible, regardless of how it was developed, and what you
chose to use or not. Most open source is written with liability clauses that
claim nothing about the proper use or safety of the software so it's
essentially buyer beware. Its free software, so what do you expect? Even
commercially supported software libraries usually have similar liability
avoidance clauses, so again, its ultimately the app owners responsibility.

So at the end of the day, the application owner is responsible for virtually
all the impact of a breach to their app, regardless of whether it's was in
their code or open source or commercial code they choose to use. And given
the high prevalence of serious vulnerabilities in open source and even
commercial libraries, this is a significant risk to the enterprises that
choose to leverage their use, and thus warrants inclusion in the Top 10 to
raise awareness of this issue, so organizations can start working on best
practices on how to minimize this risk.


-----Original Message-----
From: Christian Heinrich [mailto:christian.heinrich at cmlh.id.au] 
Sent: Saturday, May 18, 2013 11:00 PM
To: Jeff Williams; Dave Wichers
Cc: owasp-topten at lists.owasp.org
Subject: A9 - Disputed Risk

Jeff and Dave,

I have just reviewed the application of
https://www.owasp.org/index.php/Top_10_2013-Risk to
and concluded that the actual context based on the definition of A9 is
*not* a "business" risk to the developer, rather to the vendor of the
insecure software component due to liability of brand damage.

To put this another way the developer suffers little brand damage as their
public relations would be focused on shifting the blame to the vendor of the
insecure software component in order to divert the brand damage from their
(developer) brand to that of the vendor's (brand).
This also accounts for when their (vendor) license specifies that the vendor
(of the insecure software component) is not liable for any damages.

However, if the developer publishes a faulty patch for the vulnerability
identified in the insecure software component and pushes this upstream to
the vendor and is then the developer is found to be at fault then this is
the actual business risk to the developer e.g.

Based on
I believe you would concur that this context is the actual "business"
risk too.

Christian Heinrich


More information about the Owasp-topten mailing list