You are viewing a plain text version of this content. The canonical link for it is here.
Posted to security-discuss@community.apache.org by "Mark J. Cox" <mj...@apache.org> on 2021/12/28 09:00:06 UTC
Re: Introduction
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
Helpful help - was Re: Introduction
Posted by 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
Re: Introduction
Posted by Mark J Cox <mj...@apache.org>.
On Tue, Dec 28, 2021 at 1:50 PM Mark Thomas <ma...@apache.org> wrote:
<snip>
> In terms of what this means for the ASF, my thoughts are:
>
> - We should be encouraging projects to think about the NIST
> recommendations and how to apply them to their project.
>
> - 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.
>
> - We need to consider whether projects that are not releasing
> regularly really are healthy. Could they realistically respond to a
> security vulnerability in a reasonable time frame? If not, we need to
> move them to the attic.
>
And we need a clear way to communicate that, and EOL releases, to users so
they know the status of what they're using. There are quite a number of
examples where a project has responded to a vulnerability reporter that
some version is EOL but it's not been clear enough on their pages, nor any
real announcement ever having being made. We need a consistent policy on
what to do about vulnerabilities that come up in EOL versions, and when to
allocate them CVE names ('there's an unfixed issue in X") in order to help
users with scanning tools also notice when they're using out of date and
now insecure projects.
> - We should consider making SRC:CLR available as a service to projects
>
> - We need to consider how we can increase the support we provide to
> projects that need it when they are handling security vulnerabilities
>
We've never really asked projects about this. We sometimes get responses
thanking us for various help or advice or provided tools or with
suggestions for improvements, but it could be worth trying to properly
capture what help and support projects would find useful.
Mark
Re: Introduction
Posted by Mark J Cox <mj...@apache.org>.
On Wed, Dec 29, 2021 at 9:18 AM Mark Thomas <ma...@apache.org> wrote:
> On 28/12/2021 16:57, Ben Laurie wrote:
> > On Tue, 28 Dec 2021 at 16:00, Mark Thomas <ma...@apache.org> wrote:
> >> On 28/12/2021 15:30, Ben Laurie wrote:
>
> <snip/>
>
> >>> Why SRC:CLR in particular?
>
> <snip/>
>
> >>> Also, their website appears to be down/broken.
> >>
> >> They got acquired by VeraCode. I believe it is now Veracode Software
> >> Composition Analysis
> >
> > Aha. Does this mean it now costs big bucks?
>
> Possibly. Before the acquisition they approached us. It didn't pan out
> as projects didn't really engage. I imagine (or maybe hope) that the
> response would be different now.
>
> I'll check with Mark C and if he is happy for me to do so, I'll approach
> them to see what the options are.
>
+1
Mark
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>
Re: Introduction
Posted by Mark Thomas <ma...@apache.org>.
On 28/12/2021 16:57, Ben Laurie wrote:
> On Tue, 28 Dec 2021 at 16:00, Mark Thomas <ma...@apache.org> wrote:
>> On 28/12/2021 15:30, Ben Laurie wrote:
<snip/>
>>> Why SRC:CLR in particular?
<snip/>
>>> Also, their website appears to be down/broken.
>>
>> They got acquired by VeraCode. I believe it is now Veracode Software
>> Composition Analysis
>
> Aha. Does this mean it now costs big bucks?
Possibly. Before the acquisition they approached us. It didn't pan out
as projects didn't really engage. I imagine (or maybe hope) that the
response would be different now.
I'll check with Mark C and if he is happy for me to do so, I'll approach
them to see what the options are.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Introduction
Posted by Ben Laurie <be...@links.org>.
On Tue, 28 Dec 2021 at 16:00, Mark Thomas <ma...@apache.org> wrote:
> On 28/12/2021 15:30, Ben Laurie wrote:
>
> <snip/>
>
> >> - We should consider making SRC:CLR available as a service to projects
> >
> > Why SRC:CLR in particular?
>
> Because of all the tools I have seen, it is the only one with an output
> that has a decent signal to noise ratio.
>
> The short version is that it scans dependencies *and* how they are used.
> It differentiates between:
>
> - a dependency that has a known vulnerability where you do not use the
> vulnerable code path
>
> - a dependency that has a known vulnerability where you do use the
> vulnerable code path
Cool.
>
>
> > Also, their website appears to be down/broken.
>
> They got acquired by VeraCode. I believe it is now Veracode Software
> Composition Analysis
>
Aha. Does this mean it now costs big bucks?
Re: Introduction
Posted by Mark Thomas <ma...@apache.org>.
On 28/12/2021 15:30, Ben Laurie wrote:
<snip/>
>> - We should consider making SRC:CLR available as a service to projects
>
> Why SRC:CLR in particular?
Because of all the tools I have seen, it is the only one with an output
that has a decent signal to noise ratio.
The short version is that it scans dependencies *and* how they are used.
It differentiates between:
- a dependency that has a known vulnerability where you do not use the
vulnerable code path
- a dependency that has a known vulnerability where you do use the
vulnerable code path
> Also, their website appears to be down/broken.
They got acquired by VeraCode. I believe it is now Veracode Software
Composition Analysis
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Introduction
Posted by Ben Laurie <be...@links.org>.
On Tue, 28 Dec 2021 at 13:50, Mark Thomas <ma...@apache.org> wrote:
> Mark,
>
> The things covered by the EO look reasonable. While I have some comments
> on the detail of those proposals (more on that shortly), I am far more
> concerned about the significant risks that the EO appears to be ignoring.
>
> However hard we try, software is always going to have bugs and some of
> those bugs are going to have security implications. The EO addresses
> ways to reduce the frequency and severity of security vulnerabilities
> which is a good thing. What the EO appears to ignore is the (lack of)
> preparedness of some software vendors to release updated versions of
> their software and the the (lack of) preparedness of some software users
> to apply those updates.
>
> CVE-2021-44228 (the first of the recent log4j issues) exposed this because:
> a) the library is very widely used;
> b) the vulnerability is present in typical configurations; and
> c) the vulnerability is trivial to exploit.
>
> The following examples are drawn from a combination of sources, both
> recently in response to CVE-2021-44228 and historically.
>
> A query regarding exposure to CVE-2021-44228 from someone using Tomcat
> 5.5.35.
> - 5.5.x was EOL as of 2012-09-30
> - The EOL schedule for 5.5.x was announced on 2011-08-10
> - 5.5.35 was released on 2012-01-16
> So the organisation knew they were choosing a software product that
> would EOL in less than a year, chose it and then has continued to use it
> for 9+ years knowing that there are likely to be unpatched security
> vulnerabilities.
>
> Equifax and CVE-2017-5638
>
> A bug report resulting from Tomcat more strictly following the HTTP
> RFCs. Updating Tomcat for this organisation meant that the clients for
> their web application could no longer communicate with Tomcat. The
> clients were IoT devices installed in cars. There was no plan in place
> to update the the IoT device code and no willingness to develop one.
>
> Queries to the users mailing lists along the following lines:
> "Hi, I'm a system admin with no Java experience/knowledge and I have
> been tasked with addressing CVE-... for a system that uses Tomcat. What
> do I need to do?"
>
> The above are just examples. It is clear that large amounts of software
> (and this isn't limited to open source) are being deployed with little /
> no thought being given to how to support that software over its expected
> lifetime. This applies to both "in-house" applications as well as
> commercial applications.
>
> A related problem is the often significant mismatch between the lifetime
> of hardware and the support timescales of its associated software. Home
> routers, mobile phones and IoT devices are the most obvious examples
> that come to mind.
>
> I've only looked at the GDPR, particularly article 32, but I suspect a
> similar gap exists in similar legislation. The sorts of things I think
> need to be added to GDPR and/or similar/related legislation include:
>
> - A requirement for there to be the ability to update any system
> component in a timely manner should a security vulnerability be
> disclosed in that component that impacts the system.
>
> - Requirements for products that include hardware and software to
> include software updates for a minimum period. Using the UK sales of
> goods act as a basis, my starting point for that time frame is six
> years.
>
> - A requirement for all software products to state how support -
> including for security vulnerabilities - will be provided for the same
> minimum period as the previous point. This could include "paid",
> "none" etc. It shouldn't rule out any existing distribution models,
> just make the support mechanism (or lack thereof) explicit.
>
> For me, the first of the above points is the critical one. There isn't
> enough thought being given to ongoing updates. Too many organisations
> take a "Hope it doesn't happen and we'll worry about it when it does"
> approach which leads to systems that are hard to update and, as a
> result, end up exposed for significant periods of time when a
> vulnerability is disclosed.
>
>
> Getting back to the detail of the NIST recommendations stemming from the
> EO, I have already made my views on static analysis tools clear [1]
> elsewhere on this list. Other than that the recommendations seem
> reasonable to me on first reading. The challenge for many open source
> projects will be resourcing the implementation.
>
>
> In terms of what this means for the ASF, my thoughts are:
>
> - We should be encouraging projects to think about the NIST
> recommendations and how to apply them to their project.
>
> - 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.
>
> - We need to consider whether projects that are not releasing
> regularly really are healthy. Could they realistically respond to a
> security vulnerability in a reasonable time frame? If not, we need to
> move them to the attic.
>
It would be pretty interesting to maintain a list of projects that are
widely used but inadequately maintained - particularly given the bullet
above - i.e. "assign someone to look after one of these that you use".
>
> - We should consider making SRC:CLR available as a service to projects
>
Why SRC:CLR in particular? Also, their website appears to be down/broken.
>
> - We need to consider how we can increase the support we provide to
> projects that need it when they are handling security vulnerabilities
>
>
> Sorry this turned out to be rather a long email. I've been thinking
> about this quite a lot over the last few weeks. Happy to discuss any of
> the above. Given the number of different points, we might need separate
> sub-threads for each discussion point.
>
> 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
>
>
Re: Introduction
Posted by Mark Thomas <ma...@apache.org>.
Mark,
The things covered by the EO look reasonable. While I have some comments
on the detail of those proposals (more on that shortly), I am far more
concerned about the significant risks that the EO appears to be ignoring.
However hard we try, software is always going to have bugs and some of
those bugs are going to have security implications. The EO addresses
ways to reduce the frequency and severity of security vulnerabilities
which is a good thing. What the EO appears to ignore is the (lack of)
preparedness of some software vendors to release updated versions of
their software and the the (lack of) preparedness of some software users
to apply those updates.
CVE-2021-44228 (the first of the recent log4j issues) exposed this because:
a) the library is very widely used;
b) the vulnerability is present in typical configurations; and
c) the vulnerability is trivial to exploit.
The following examples are drawn from a combination of sources, both
recently in response to CVE-2021-44228 and historically.
A query regarding exposure to CVE-2021-44228 from someone using Tomcat
5.5.35.
- 5.5.x was EOL as of 2012-09-30
- The EOL schedule for 5.5.x was announced on 2011-08-10
- 5.5.35 was released on 2012-01-16
So the organisation knew they were choosing a software product that
would EOL in less than a year, chose it and then has continued to use it
for 9+ years knowing that there are likely to be unpatched security
vulnerabilities.
Equifax and CVE-2017-5638
A bug report resulting from Tomcat more strictly following the HTTP
RFCs. Updating Tomcat for this organisation meant that the clients for
their web application could no longer communicate with Tomcat. The
clients were IoT devices installed in cars. There was no plan in place
to update the the IoT device code and no willingness to develop one.
Queries to the users mailing lists along the following lines:
"Hi, I'm a system admin with no Java experience/knowledge and I have
been tasked with addressing CVE-... for a system that uses Tomcat. What
do I need to do?"
The above are just examples. It is clear that large amounts of software
(and this isn't limited to open source) are being deployed with little /
no thought being given to how to support that software over its expected
lifetime. This applies to both "in-house" applications as well as
commercial applications.
A related problem is the often significant mismatch between the lifetime
of hardware and the support timescales of its associated software. Home
routers, mobile phones and IoT devices are the most obvious examples
that come to mind.
I've only looked at the GDPR, particularly article 32, but I suspect a
similar gap exists in similar legislation. The sorts of things I think
need to be added to GDPR and/or similar/related legislation include:
- A requirement for there to be the ability to update any system
component in a timely manner should a security vulnerability be
disclosed in that component that impacts the system.
- Requirements for products that include hardware and software to
include software updates for a minimum period. Using the UK sales of
goods act as a basis, my starting point for that time frame is six
years.
- A requirement for all software products to state how support -
including for security vulnerabilities - will be provided for the same
minimum period as the previous point. This could include "paid",
"none" etc. It shouldn't rule out any existing distribution models,
just make the support mechanism (or lack thereof) explicit.
For me, the first of the above points is the critical one. There isn't
enough thought being given to ongoing updates. Too many organisations
take a "Hope it doesn't happen and we'll worry about it when it does"
approach which leads to systems that are hard to update and, as a
result, end up exposed for significant periods of time when a
vulnerability is disclosed.
Getting back to the detail of the NIST recommendations stemming from the
EO, I have already made my views on static analysis tools clear [1]
elsewhere on this list. Other than that the recommendations seem
reasonable to me on first reading. The challenge for many open source
projects will be resourcing the implementation.
In terms of what this means for the ASF, my thoughts are:
- We should be encouraging projects to think about the NIST
recommendations and how to apply them to their project.
- 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.
- We need to consider whether projects that are not releasing
regularly really are healthy. Could they realistically respond to a
security vulnerability in a reasonable time frame? If not, we need to
move them to the attic.
- We should consider making SRC:CLR available as a service to projects
- We need to consider how we can increase the support we provide to
projects that need it when they are handling security vulnerabilities
Sorry this turned out to be rather a long email. I've been thinking
about this quite a lot over the last few weeks. Happy to discuss any of
the above. Given the number of different points, we might need separate
sub-threads for each discussion point.
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
Re: SBOM - was Re: Introduction
Posted by sebb <se...@gmail.com>.
On Tue, 28 Dec 2021 at 15:44, David Nalley <da...@gnsa.us> wrote:
>
> There's so much to this email that I think it would take me a long while to
> respond, so I am breaking off in small bits.
>
> On Tue, Dec 28, 2021 at 4:00 AM Mark J. Cox <mj...@apache.org> wrote:
>
> >
> > - 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)
> >
> >
> So, producing an SBOM, whether of source or binary isn't a huge technical
> challenge for most codebases these days. But, are we really talking about
> mandating projects produce an SBOM for each release? I am fine if that's
> the case, but if it's not required, it won't happen, IMO and that makes all
> follow on conversation largely pointless.
>
> But going on the assumption that we require SBOMs for all releases. Now we
> need a way to store those (and there are tools) for later querying. Would
> we make that publicly accessible or only internally accessible? I could see
> arguments both ways.
>
> The real inhibitor that I worry about is the really long tail of releases
> that Mark talks about. While we should get started on SBOM, a lot of the
> value disappears for us if we only have the last couple of releases
> producing BOMs. I wonder if it's worth considering producing SBOMs for
> historic releases. I don't think we can mandate that, but it might be
> something that is easily funded or we assign folks work for.
>
> I could also see an AppSec-type future where the Security organizations
> sees a really bad vulnerability in a third-party library, and uses SBOM
> records to alert projects that they are consuming it. (Though Dependabot on
> GH does a lot of this today for certain languages)
GH Dependabot certainly does a lot: it warns you about *every* change
to a dependency.
It floods mailing lists with messages, mostly just noise (just look at Commons)
> --David
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
SBOM - was Re: Introduction
Posted by David Nalley <da...@gnsa.us>.
There's so much to this email that I think it would take me a long while to
respond, so I am breaking off in small bits.
On Tue, Dec 28, 2021 at 4:00 AM Mark J. Cox <mj...@apache.org> wrote:
>
> - 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)
>
>
So, producing an SBOM, whether of source or binary isn't a huge technical
challenge for most codebases these days. But, are we really talking about
mandating projects produce an SBOM for each release? I am fine if that's
the case, but if it's not required, it won't happen, IMO and that makes all
follow on conversation largely pointless.
But going on the assumption that we require SBOMs for all releases. Now we
need a way to store those (and there are tools) for later querying. Would
we make that publicly accessible or only internally accessible? I could see
arguments both ways.
The real inhibitor that I worry about is the really long tail of releases
that Mark talks about. While we should get started on SBOM, a lot of the
value disappears for us if we only have the last couple of releases
producing BOMs. I wonder if it's worth considering producing SBOMs for
historic releases. I don't think we can mandate that, but it might be
something that is easily funded or we assign folks work for.
I could also see an AppSec-type future where the Security organizations
sees a really bad vulnerability in a third-party library, and uses SBOM
records to alert projects that they are consuming it. (Though Dependabot on
GH does a lot of this today for certain languages)
--David