Helpful help - was Re: Introduction

[Phil Steitz <ph...@steitz.com>]

Following David's lead, I will comment on just one of the meaty topics 
raised below.

<snip>
>
> In terms of what this means for the ASF, my thoughts are:
>
>
> - We should think about what our answer should be when organisations ask
>   "How can we help?". Donations of cash, hardware and/or services will
>   be part of it but I think we a response that includes allocating
>   employees to contribute to projects and how we help organisations
>   and individuals do that who are unfamiliar with how the ASF works.
>
This is hard.  What we need is engaged eyeballs willing and able to 
contribute to projects.  And often the projects in need are not that 
active, so engagement and acculturation may be difficult to start. Add 
to that the typical $bigco incentive structure (get *your* stuff 
shipped) and you have a hard startup problem.  Add further the classic 
security guys vs. developers conflict and you have what looks like a 
really hard problem.

But hard != impossible.  All of the press and growing understanding of 
materiality of risk creates opportunity to align incentive structures.  
Other great stuff in this message about regs, etc. can help, but we also 
need to make sure people understand the depth and nature of the problem, 
not just as an imminent threat to their near term business objectives 
but as a long-term threat to the sustainability of the larger software 
ecosystem that they depend on.  We need people to think about OSS 
security and reliability like they do about global warming - something 
requiring collective action, not something for somebody else to worry 
about.  We also need to get them to understand that you can't "inspect 
in" security - sustainable solutions require that those who can spot 
things get their eyeballs on the code as it is being committed.

Then we need to provide some getting started help, likely in two forms 
0) program templates for already clueful leaders and b) educational 
material for people needing to get their leaders support.   I wonder if 
some of the companies already engaged have materials that we could 
bootstrap with?  I have experimented with several different kinds of 
programs but have never really done it at scale.  I know some companies 
have and a kind of adjunct to the incubator for security / maintenance 
help might make sense.

Phil
>
> Mark
>
>
> [1] https://lists.apache.org/thread/54fpkghfrt4lophrf7q819fntnz9vzxq
>
>
>
> On 28/12/2021 09:00, Mark J. Cox wrote:
>> Given the White House in the last week has announced[1] enlisting the 
>> industry to improve open-source security it's worth revisiting this 
>> thread.
>>
>> Although we don't really know what the meeting will cover, I could 
>> assume it could be looking at the existing executive order and how to 
>> make or help open source align/comply.  Log4J being at the forefront 
>> of everyone's mind may make the input from ASF even more relevant.
>>
>> So what kind of things are covered by the EO?
>>
>> - attesting software conforms to some secure development practices 
>> (practices tbd by NIST but will cover things like testing etc [2]), 
>> and then labeling what you ship so people know what you did.  (see 
>> https://slsa.dev/ part of OpenSSF).  Many of these initiatives have a 
>> heavy focus on 'builds' being binaries which are not what most of our 
>> projects produce.
>>
>> - employ tools to maintain trusted supply chains (signing, etc, but 
>> also ensuring you check dependencies)
>>
>> - deliver bills of materials (SBOM). Although with OSS you can just 
>> use some scanners we could certainly help projects to start producing 
>> them, particularly for those projects that are consuming libraries 
>> from other ASF projects (i.e. the ASF security team would have been 
>> able to simply grep these manifests for projects using and including 
>> vulnerable versions of log4j)
>>
>> - identify what is critical software through some future definition 
>> of critical.  OpenSSF are trying this for OSS in numbers of ways but 
>> their automation doesn't score ASF projects particularly well.  
>> (OpenSSF and Linux Foundation have lots of projects around all these 
>> things [3])
>>
>> - a vulnerability disclosure policy (we have processes and policy 
>> that already meet the guidelines)
>>
>> There's plausibly some things that would make sense for ASF to 
>> explore doing - for example SBOMs/labelling t and ensuring our 
>> vulnerability disclosure policy is published in a way that shows how 
>> we meed the guidelines.  And having some better policy around any 
>> binaries (convenience) shipped.
>>
>> Mark
>>
>> [1] 
>> https://www.bloomberg.com/news/articles/2021-12-23/white-house-extends-invitation-to-improve-open-source-security
>> [2] 
>> https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/enhancing-software-supply-chain-security
>> [3] 
>> https://www.linuxfoundation.org/blog/how-lf-communities-enable-security-measures-required-by-the-us-executive-order-on-cybersecurity/
>>
>> On 2021/09/22 12:20:49 Mark J Cox wrote:
>>> With US releasing a security Executive Order focused on supply-chain
>>> security we see many third parties find they need to account for the
>>> security and provenance of open source software.  Now, more than ever,
>>> companies want to do something to help, but they're not sure how.  
>>> Or they
>>> know how and have a plan but they're coming up with ideas without
>>> understanding how Open Source communities work.
>>>
>>> The NIST guidelines created so far for the Order actually give some
>>> reasonable steps[1] to help improve security, and while we already 
>>> do some
>>> of these things in some of our projects, we've never really had a 
>>> place to
>>> talk about that on a public list.  So while every ASF project is
>>> responsible for their own technical aspects of dealing with their 
>>> code, and
>>> while we want to always minimise the number of actual things that are
>>> policies, that doesn't mean we can't find areas of commonality.
>>>
>>> Therefore the aim of this list is to look at some of the recommended 
>>> and
>>> new practices and guidelines.  See how initiatives such as the projects
>>> from the OpenSSF might work for us.  Many of the current OpenSSF 
>>> projects
>>> publish data about ASF projects but it's not accurate because it 
>>> assumes
>>> things like github being the primary development platform.  We need 
>>> to help
>>> fix these things as they're going to be created and used anyway.
>>>
>>> But also we can use this as a place where we can see what things our 
>>> ASF
>>> projects currently do and how we can spread that knowledge. And it's 
>>> here,
>>> in the community development PMC, because this conversation isn't 
>>> one owned
>>> or managed by the Security Committee.
>>>
>>> [1]
>>> https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/recommended-minimum-standards-vendor-or 
>>>
>>>
>>> Regards, Mark
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 
>> security-discuss-unsubscribe@community.apache.org
>> For additional commands, e-mail: 
>> security-discuss-help@community.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail: 
> security-discuss-help@community.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org