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 Hen <ba...@apache.org> on 2021/12/18 22:52:02 UTC
Suggested process enhancement
I was looking at Andrew's excellent clarifications to the CVE process
language ( https://github.com/apache/www-site/pull/109 ), and one out of
scope thought I had was to add a couple of steps/substeps.
Currently it says:
"The project team commits the fix. Do not make any reference that the
commit relates to a security vulnerability."
I was wondering on stretching that out into the larger text of:
"The project creates a plan for committing the fix and reviews this
with the Security Team. Once approved, the project team commits the fix.
This commit will not make any reference that the commit relates to a
security vulnerability."
Thanks,
Hen
[relevant page: https://www.apache.org/security/committers.html ]
Re: Suggested process enhancement
Posted by sebb <se...@gmail.com>.
On Wed, 22 Dec 2021 at 12:35, Mark Thomas <ma...@apache.org> wrote:
>
> On 21/12/2021 23:55, Hen wrote:
>
> <snip/>
>
> > Dependabot-on-GitHub wise, there is a dashboard but presumably only visible
> > to the organization owners. The new Repository roles maybe could be used to
> > create a Security role who can see it for all repos without making the
> > Security Team Owners on the organization.
> >
> > Can also write GH API code to pull the data; though doing it as a GH Action
> > is probably better if we're hitting the 5,000 PAT limits.
>
> Personally, I *really* don't like dependabot. The volume of noise it has
> created in Apache Commons is significant. To the point that, in my view,
> it is harming the community because the volume of mail from dependabot
> is drowning out other conversations.
+1
At least half of the commits@commons emails are now related to
dependabot, similarly for issues@
> The thing is, an out of date dependency isn't necessarily an issue -
> even if that dependency has known security issues. What matters is how
> the dependency is used.
Indeed
Another issue is that some dependencies are released much more
frequently than the code which uses them.
It's not unknown in Commons for a single component to have multiple
dependabot reports for the same dependency by the time the next
release is ready. Only the last report for each dependency has any
possible relevance. It's much more efficient to run a Maven dependency
check when preparing a release.
<snip>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Suggested process enhancement
Posted by Mark Thomas <ma...@apache.org>.
On 21/12/2021 23:55, Hen wrote:
<snip/>
> Dependabot-on-GitHub wise, there is a dashboard but presumably only visible
> to the organization owners. The new Repository roles maybe could be used to
> create a Security role who can see it for all repos without making the
> Security Team Owners on the organization.
>
> Can also write GH API code to pull the data; though doing it as a GH Action
> is probably better if we're hitting the 5,000 PAT limits.
Personally, I *really* don't like dependabot. The volume of noise it has
created in Apache Commons is significant. To the point that, in my view,
it is harming the community because the volume of mail from dependabot
is drowning out other conversations.
The thing is, an out of date dependency isn't necessarily an issue -
even if that dependency has known security issues. What matters is how
the dependency is used. We ran a trial of SRC:CLR (source clear - since
acquired by VeraCode) a few years ago and it was enlightening. SRC:CLR's
USP was that it checked how dependencies were used so you could
prioritise updating the dependencies that actually needed to be updated.
Roughly, only about 10% of dependencies with known vulnerabilities were
being used in a way that exposed the vulnerability.
I think there is value in using the SRC:CLR service although we may have
to pay for it. The challenge is that the projects didn't seem that
interested. Times have changed since then though.
While I am on my hobby horse, and on a closely related topic, I also
have next to no time for static analysis tools. They might work well for
applications but I have never seen one work well for infrastructure code
(Tomcat, Commons etc.). Way too many false positives. Also, when we look
back at historical scans where we now know a vulnerability was present,
we can see that the static analysis missed it. And I've seen a couple
over the years that I would have expected to be caught.
What does work well are tools like SpotBugs (formerly FindBugs). I also
like code formatting tools on the basis that a standard format makes the
code easier to read and hence understand - and spot bugs.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Suggested process enhancement
Posted by Hen <ba...@apache.org>.
On Tue, Dec 21, 2021 at 4:19 AM Mads Toftum <ma...@toftum.dk> wrote:
> On Tue, Dec 21, 2021 at 10:54:08AM +0000, Mark Thomas wrote:
> > On 21/12/2021 09:35, Hen wrote:
> >
> > The inactive projects will have been moved to the attic. A bigger
> > issue - in my view - is the projects that are on the cusp of moving
> > to the attic. They have enough activity to move forward just enough
> > to avoid the attic but not enough to react to a security issue.
> > There are projects that have vulnerabilities that have remained
> > unaddressed for far too long.
> >
> > Too long is subjective and will vary by circumstance but I think
> > there comes a point when a project's failure to make meaningful
> > progress to address a security issue in a reasonable time frame
> > should result in the project being moved to the attic.
> >
> Perhaps missing responses on security issues could be used as a
> first indication that a move to attic should be discussed?
>
I obviously like the idea, but I've a scythe and hood in a cupboard
somewhere.
>
> > >It's a hard one to fix, assuming it should be fixed. Personally I think
> > >there should be some kind of alert when a project moves to the Attic.
>
> Right now there's an email going to a projects list as part of the attic
> process. https://attic.apache.org/process.html
> >
> > There should be an email to announce@.
> >
> I think that would be simple enough to roll into the attic process.
>
I was thinking of something more like the CVE process. I see a lot of focus
in the industry/community over project health, but we don't even have a
common way to identify dead-parrots. What I'd love to do as a user who is a
bear of large size is to ingest a stream of events that equate to "This
project is no more. It has ceased to be.".
That may be too pat though. Building/buying algorithms that determine
likelihood of a release happening if needed may be the only way to go.
We'll probably never get to a place where folk are turning the lights off
across popular open source as a whole.
>
> > Email to all PMCs would likely be noise for most PMCs and targetting
> > an email would require knowledge of dependencies.
> >
> Agreed.
>
+1. I'm thinking of user pull rather than push to PMCs.
>
> > Generally, I'd expect projects to be reviewing their dependencies
> > fairly regularly.
> >
> Do we or could we have build tools that report on this?
>
Dependabot-on-GitHub wise, there is a dashboard but presumably only visible
to the organization owners. The new Repository roles maybe could be used to
create a Security role who can see it for all repos without making the
Security Team Owners on the organization.
Can also write GH API code to pull the data; though doing it as a GH Action
is probably better if we're hitting the 5,000 PAT limits.
Hen
Re: Suggested process enhancement
Posted by Mads Toftum <ma...@toftum.dk>.
On Tue, Dec 21, 2021 at 10:54:08AM +0000, Mark Thomas wrote:
> On 21/12/2021 09:35, Hen wrote:
>
> The inactive projects will have been moved to the attic. A bigger
> issue - in my view - is the projects that are on the cusp of moving
> to the attic. They have enough activity to move forward just enough
> to avoid the attic but not enough to react to a security issue.
> There are projects that have vulnerabilities that have remained
> unaddressed for far too long.
>
> Too long is subjective and will vary by circumstance but I think
> there comes a point when a project's failure to make meaningful
> progress to address a security issue in a reasonable time frame
> should result in the project being moved to the attic.
>
Perhaps missing responses on security issues could be used as a
first indication that a move to attic should be discussed?
> >It's a hard one to fix, assuming it should be fixed. Personally I think
> >there should be some kind of alert when a project moves to the Attic.
Right now there's an email going to a projects list as part of the attic
process. https://attic.apache.org/process.html
>
> There should be an email to announce@.
>
I think that would be simple enough to roll into the attic process.
> Email to all PMCs would likely be noise for most PMCs and targetting
> an email would require knowledge of dependencies.
>
Agreed.
> Generally, I'd expect projects to be reviewing their dependencies
> fairly regularly.
>
Do we or could we have build tools that report on this?
vh
Mads Toftum
--
http://flickr.com/photos/q42/
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Suggested process enhancement
Posted by Mark Thomas <ma...@apache.org>.
On 21/12/2021 09:35, Hen wrote:
> On Mon, Dec 20, 2021 at 1:35 AM Mark J Cox <mj...@apache.org> wrote:
>
>> Mark is right; we've got several hundred projects and they all work
>> differently. Some have lots of resources, handle lots of issues, and have
>> mature and working processes for getting releases out. Others either handle
>> security issues infrequently or are struggling for resources and we need to
>> give them some help. The ASF security team provides and maintains the
>> common required process all projects need to follow to handle their
>> reported security issues, and we provide as much help and guidance as we
>> can on how they can get through them. (the yearly report gives a good
>> overview, here's the one for 2020:
>>
>> https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
>> )
>>
>
> Thanks :)
>
> I also enjoyed finding https://www.apache.org/security/projects.html as a
> nice list of the various Security project-teams.
>
> My assumption on the history is that initially the Security Team was HTTP
> Server focused (yourself, Bill? Ben?), and then as Tomcat grew the Tomcat
> Security work led to MarkT joining in. Are others of the projects with
> mature processes finding themselves getting more involved in the overall
> Security Team as a whole? I wonder if there are clumping strategies we
> could use; for example I imagine despite not being listed that the Tomcat
> Security team handle Commons FileUpload [assuming I'm not way out of date
> and it's still used].
The Commons team handle that. While I am on the Commons PMC, I don't get
too involved in the Commons security issues apart from the odd bit of
advice from time to time.
>> Those projects that struggle for resources need help from more than what a
>> PSIRT-like team can provide; what they need are people in their project
>> able to write and test code, able to do releases, people that really
>> understand how the project is used and the community around it.
>>
>
> My initial instinct is that "sure, but that's just projects becoming
> inactive". Which I think is true, but I wonder if you're saying that
> inactive projects are one of our larger security-related issues?
The inactive projects will have been moved to the attic. A bigger issue
- in my view - is the projects that are on the cusp of moving to the
attic. They have enough activity to move forward just enough to avoid
the attic but not enough to react to a security issue. There are
projects that have vulnerabilities that have remained unaddressed for
far too long.
Too long is subjective and will vary by circumstance but I think there
comes a point when a project's failure to make meaningful progress to
address a security issue in a reasonable time frame should result in the
project being moved to the attic.
> It's a hard one to fix, assuming it should be fixed. Personally I think
> there should be some kind of alert when a project moves to the Attic.
There should be an email to announce@.
Email to all PMCs would likely be noise for most PMCs and targetting an
email would require knowledge of dependencies.
Generally, I'd expect projects to be reviewing their dependencies fairly
regularly.
> Common Deprecation Event :) And possibly the 'investment' is in putting
> more energy into how to move off of the now mothballed project.
>
> What do we do when a security issue is reported in an Attic'd project?
It would normally be rejected as the project is no longer supported.
Mark
>> I'd also like to see us have people work more closely with the various
>> OpenSSF initiatives. OpenSSF have a number of interesting projects that
>> are trying to understand and address problems that have come up with OSS
>> many of which would benefit from people with security and specifically
>> Apache projects experience.
>>
>
> As in, if you had a volunteer today you would ask them to volunteer to the
> OpenSSF, or you'd like to connect some of the mature security-minded
> projects to the OpenSSF, or ... ?
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org
Re: Suggested process enhancement
Posted by Hen <ba...@apache.org>.
On Mon, Dec 20, 2021 at 1:35 AM Mark J Cox <mj...@apache.org> wrote:
> Mark is right; we've got several hundred projects and they all work
> differently. Some have lots of resources, handle lots of issues, and have
> mature and working processes for getting releases out. Others either handle
> security issues infrequently or are struggling for resources and we need to
> give them some help. The ASF security team provides and maintains the
> common required process all projects need to follow to handle their
> reported security issues, and we provide as much help and guidance as we
> can on how they can get through them. (the yearly report gives a good
> overview, here's the one for 2020:
>
> https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
> )
>
Thanks :)
I also enjoyed finding https://www.apache.org/security/projects.html as a
nice list of the various Security project-teams.
My assumption on the history is that initially the Security Team was HTTP
Server focused (yourself, Bill? Ben?), and then as Tomcat grew the Tomcat
Security work led to MarkT joining in. Are others of the projects with
mature processes finding themselves getting more involved in the overall
Security Team as a whole? I wonder if there are clumping strategies we
could use; for example I imagine despite not being listed that the Tomcat
Security team handle Commons FileUpload [assuming I'm not way out of date
and it's still used].
>
> Those projects that struggle for resources need help from more than what a
> PSIRT-like team can provide; what they need are people in their project
> able to write and test code, able to do releases, people that really
> understand how the project is used and the community around it.
>
My initial instinct is that "sure, but that's just projects becoming
inactive". Which I think is true, but I wonder if you're saying that
inactive projects are one of our larger security-related issues?
It's a hard one to fix, assuming it should be fixed. Personally I think
there should be some kind of alert when a project moves to the Attic.
Common Deprecation Event :) And possibly the 'investment' is in putting
more energy into how to move off of the now mothballed project.
What do we do when a security issue is reported in an Attic'd project?
>
> I'd also like to see us have people work more closely with the various
> OpenSSF initiatives. OpenSSF have a number of interesting projects that
> are trying to understand and address problems that have come up with OSS
> many of which would benefit from people with security and specifically
> Apache projects experience.
>
As in, if you had a volunteer today you would ask them to volunteer to the
OpenSSF, or you'd like to connect some of the mature security-minded
projects to the OpenSSF, or ... ?
Hen
Re: Suggested process enhancement
Posted by Mark J Cox <mj...@apache.org>.
Mark is right; we've got several hundred projects and they all work
differently. Some have lots of resources, handle lots of issues, and have
mature and working processes for getting releases out. Others either handle
security issues infrequently or are struggling for resources and we need to
give them some help. The ASF security team provides and maintains the
common required process all projects need to follow to handle their
reported security issues, and we provide as much help and guidance as we
can on how they can get through them. (the yearly report gives a good
overview, here's the one for 2020:
https://blogs.apache.org/foundation/entry/apache-software-foundation-security-report1
)
Those projects that struggle for resources need help from more than what a
PSIRT-like team can provide; what they need are people in their project
able to write and test code, able to do releases, people that really
understand how the project is used and the community around it.
I'd also like to see us have people work more closely with the various
OpenSSF initiatives. OpenSSF have a number of interesting projects that
are trying to understand and address problems that have come up with OSS
many of which would benefit from people with security and specifically
Apache projects experience.
Regards, Mark J Cox
ASF Security
Re: Suggested process enhancement
Posted by Hen <ba...@apache.org>.
On Sun, Dec 19, 2021 at 2:40 AM Mark Thomas <ma...@apache.org> wrote:
> On 18/12/2021 22:52, Hen wrote:
> > I was looking at Andrew's excellent clarifications to the CVE process
> > language ( https://github.com/apache/www-site/pull/109 ), and one out of
> > scope thought I had was to add a couple of steps/substeps.
> >
> > Currently it says:
> >
> > "The project team commits the fix. Do not make any reference that
> the
> > commit relates to a security vulnerability."
> >
> > I was wondering on stretching that out into the larger text of:
> >
> > "The project creates a plan for committing the fix and reviews this
> > with the Security Team. Once approved, the project team commits the fix.
> > This commit will not make any reference that the commit relates to a
> > security vulnerability."
>
> I think this has hit the nail on the head regarding a key problem: How
> to educate project teams about the difficulties of navigating that fine
> line between having to to commit the fix to a public repository without
> giving away the fact that the commit is addressing a security
> vulnerability.
>
> I don't think there is a one size fits all solution to this. Some
> projects have been doing this successfully for years (decades even for
> some) and we don't want to add overhead to those projects.
>
> At the other end of the spectrum there are projects that have never
> received a vulnerability report before. When a project's processes are
> set up to do things in public, it is all too easy for information to
> accidentally leak via a public bug report, PR or similar created in
> response to a security issue.
>
> I don't have a good solution for this.
>
> In outline, the solution is almost certainly more input from those with
> experience of handling security issues. It is the detail of how to do
> that I don't have. Whether those with the necessary experience are
> willing and able to volunteer the time required is a separate
> question/problem.
>
Thinking Apache style. In terms of 'some are experienced and some are not',
perhaps invite the experienced folk to become Security Team members.
Watching you operate from afar, I still feel I see you getting peer review
on your plans. So we would have the "a Security Team member (not the lead
on the issue) peer reviews" stage, and then we have an Apache style
nomination for those who have led security issues to the Security Team's
satisfaction that they could lead an issue for a project they are not
expert in.
I agree that finding the necessary volunteers is a challenge, but that's
going to be a general challenge for anything we look to improve here. For
example, it would be really valuable to write educational post-mortems, but
that means someone interviewing those who were involved and writing
content. I think at the moment what we (ASF) do is brainstorm ideas for
things that will help, and then look to see who can help and how we can
extend the trust. I'm assuming that for the next 3 months there is going to
be greater intentions than usual to get involved.
On extending trust difficulties, it would be awesome to have paid first
responders on reported issues as that's high burnout for a volunteer (I'm
guessing), but I don't see us being happy with a corporation offering up
some random frontline support folk to hear about delicate issues. I'm quite
intrigued by how the Linux distros@ security mailing list works and whether
there are ideas that could be adapted from there.
Hen
[I feel bad throwing the 'we' around a bit above as I feel I only have a
very bad crayon drawing idea of the problems faced and expertise required;
apologies if any of my comments feel hugely presumptive]
Re: Suggested process enhancement
Posted by Mark Thomas <ma...@apache.org>.
On 19/12/2021 18:56, John Kinsella wrote:
> Mark, you've been handling security issues for years? :)
>
> One option could be to commit the fix - with a commit message indicating
> it's a security fix - in a private repo/branch. Include necessary
> contributors to test the fix, then as the vuln announcement goes out, merge
> the fix branch into the public repo (I get that this confuses the standard
> release process). That said, glancing at the older CloudStack security
> guidance that I put together[1], I didn't suggest that back then. Can't
> remember if I was following ASF guidance or if there was some thought
> behind that...
The issue with the above approach is that it breaks the release process
and/or makes it obvious there is a security fix in the release.
One of the checks release reviewers should be performing is checking
that the public tag and the source tarball are identical. If the release
is built from a private branch the public tag will not be consistent.
> With my mentor/educator/podcaster hat on, I really like guiding folks to
> look at commits in OSS projects that mitigate security issues. Besides
> showing "real world" mitigations of issues, often the fix isn't as simple
> as one would think and that becomes a great learning experience. When I
> have time I'll dig through commits to find the mitigation, but it's a lot
> easier for all if it's clearly called out.
Agreed. Tomcat includes commit references when we publish CVEs on our
security page. That isn't in ASF guidance but it is worth considering
adding that.
> Separately - reading the PR I noticed current ASF security guidance
> mentions not creating Jiras for security issues: We've had the ability to
> add "security" flags in Jira to allow issues to be non-public until
> intended release. I know this took a bit of management on infra's side, but
> it seemed to work well. I'm not sure if that functionality has fallen out
> of favor, but if not, I tend to lean towards documentation/transparency as
> the tech allows it. [2]
Private Jira (or Bugzilla for the few projects still using it) are fine
if the project wants to do that. The guidance can be updated to include
that.
> John
>
> 1:
> https://web.archive.org/web/20190416025112/https://cloudstack.apache.org/security.html
> 2: For Github - folks have been asking for "private" issues for a few
> years, last time I checked that's still not possible AFAIK. I guess if they
> did implement that, they could also add support for private branches, which
> could help this discussion a lot...
Potentially.
I often use local git branches for security fixes. I assume the other
Tomcat committers do something similar. We share proposed fixes, test
cases etc as diffs over email using the security@tomcat.a.o list.
While this approach may look overly burdensome, in practise the
additional overhead is minimal and I think there are real benefits both
to having a completely different process and that that process is more
detached. It helps to create a clear separation between normal issues
and security issues. Having to switch your way of working helps you to
switch from "normal issue" to "security issue" mode and the additional
separation reduces the chances of an inadvertent command making
something public sooner than intended.
Mark
>
> On Sun, Dec 19, 2021 at 2:41 AM Mark Thomas <ma...@apache.org> wrote:
>
>> On 18/12/2021 22:52, Hen wrote:
>>> I was looking at Andrew's excellent clarifications to the CVE process
>>> language ( https://github.com/apache/www-site/pull/109 ), and one out of
>>> scope thought I had was to add a couple of steps/substeps.
>>>
>>> Currently it says:
>>>
>>> "The project team commits the fix. Do not make any reference that
>> the
>>> commit relates to a security vulnerability."
>>>
>>> I was wondering on stretching that out into the larger text of:
>>>
>>> "The project creates a plan for committing the fix and reviews this
>>> with the Security Team. Once approved, the project team commits the fix.
>>> This commit will not make any reference that the commit relates to a
>>> security vulnerability."
>>
>> I think this has hit the nail on the head regarding a key problem: How
>> to educate project teams about the difficulties of navigating that fine
>> line between having to to commit the fix to a public repository without
>> giving away the fact that the commit is addressing a security
>> vulnerability.
>>
>> I don't think there is a one size fits all solution to this. Some
>> projects have been doing this successfully for years (decades even for
>> some) and we don't want to add overhead to those projects.
>>
>> At the other end of the spectrum there are projects that have never
>> received a vulnerability report before. When a project's processes are
>> set up to do things in public, it is all too easy for information to
>> accidentally leak via a public bug report, PR or similar created in
>> response to a security issue.
>>
>> I don't have a good solution for this.
>>
>> In outline, the solution is almost certainly more input from those with
>> experience of handling security issues. It is the detail of how to do
>> that I don't have. Whether those with the necessary experience are
>> willing and able to volunteer the time required is a separate
>> question/problem.
>>
>> 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: Suggested process enhancement
Posted by John Kinsella <jl...@gmail.com>.
Mark, you've been handling security issues for years? :)
One option could be to commit the fix - with a commit message indicating
it's a security fix - in a private repo/branch. Include necessary
contributors to test the fix, then as the vuln announcement goes out, merge
the fix branch into the public repo (I get that this confuses the standard
release process). That said, glancing at the older CloudStack security
guidance that I put together[1], I didn't suggest that back then. Can't
remember if I was following ASF guidance or if there was some thought
behind that...
With my mentor/educator/podcaster hat on, I really like guiding folks to
look at commits in OSS projects that mitigate security issues. Besides
showing "real world" mitigations of issues, often the fix isn't as simple
as one would think and that becomes a great learning experience. When I
have time I'll dig through commits to find the mitigation, but it's a lot
easier for all if it's clearly called out.
Separately - reading the PR I noticed current ASF security guidance
mentions not creating Jiras for security issues: We've had the ability to
add "security" flags in Jira to allow issues to be non-public until
intended release. I know this took a bit of management on infra's side, but
it seemed to work well. I'm not sure if that functionality has fallen out
of favor, but if not, I tend to lean towards documentation/transparency as
the tech allows it. [2]
John
1:
https://web.archive.org/web/20190416025112/https://cloudstack.apache.org/security.html
2: For Github - folks have been asking for "private" issues for a few
years, last time I checked that's still not possible AFAIK. I guess if they
did implement that, they could also add support for private branches, which
could help this discussion a lot...
On Sun, Dec 19, 2021 at 2:41 AM Mark Thomas <ma...@apache.org> wrote:
> On 18/12/2021 22:52, Hen wrote:
> > I was looking at Andrew's excellent clarifications to the CVE process
> > language ( https://github.com/apache/www-site/pull/109 ), and one out of
> > scope thought I had was to add a couple of steps/substeps.
> >
> > Currently it says:
> >
> > "The project team commits the fix. Do not make any reference that
> the
> > commit relates to a security vulnerability."
> >
> > I was wondering on stretching that out into the larger text of:
> >
> > "The project creates a plan for committing the fix and reviews this
> > with the Security Team. Once approved, the project team commits the fix.
> > This commit will not make any reference that the commit relates to a
> > security vulnerability."
>
> I think this has hit the nail on the head regarding a key problem: How
> to educate project teams about the difficulties of navigating that fine
> line between having to to commit the fix to a public repository without
> giving away the fact that the commit is addressing a security
> vulnerability.
>
> I don't think there is a one size fits all solution to this. Some
> projects have been doing this successfully for years (decades even for
> some) and we don't want to add overhead to those projects.
>
> At the other end of the spectrum there are projects that have never
> received a vulnerability report before. When a project's processes are
> set up to do things in public, it is all too easy for information to
> accidentally leak via a public bug report, PR or similar created in
> response to a security issue.
>
> I don't have a good solution for this.
>
> In outline, the solution is almost certainly more input from those with
> experience of handling security issues. It is the detail of how to do
> that I don't have. Whether those with the necessary experience are
> willing and able to volunteer the time required is a separate
> question/problem.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
> For additional commands, e-mail:
> security-discuss-help@community.apache.org
>
>
Re: Suggested process enhancement
Posted by Mark Thomas <ma...@apache.org>.
On 18/12/2021 22:52, Hen wrote:
> I was looking at Andrew's excellent clarifications to the CVE process
> language ( https://github.com/apache/www-site/pull/109 ), and one out of
> scope thought I had was to add a couple of steps/substeps.
>
> Currently it says:
>
> "The project team commits the fix. Do not make any reference that the
> commit relates to a security vulnerability."
>
> I was wondering on stretching that out into the larger text of:
>
> "The project creates a plan for committing the fix and reviews this
> with the Security Team. Once approved, the project team commits the fix.
> This commit will not make any reference that the commit relates to a
> security vulnerability."
I think this has hit the nail on the head regarding a key problem: How
to educate project teams about the difficulties of navigating that fine
line between having to to commit the fix to a public repository without
giving away the fact that the commit is addressing a security vulnerability.
I don't think there is a one size fits all solution to this. Some
projects have been doing this successfully for years (decades even for
some) and we don't want to add overhead to those projects.
At the other end of the spectrum there are projects that have never
received a vulnerability report before. When a project's processes are
set up to do things in public, it is all too easy for information to
accidentally leak via a public bug report, PR or similar created in
response to a security issue.
I don't have a good solution for this.
In outline, the solution is almost certainly more input from those with
experience of handling security issues. It is the detail of how to do
that I don't have. Whether those with the necessary experience are
willing and able to volunteer the time required is a separate
question/problem.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscribe@community.apache.org
For additional commands, e-mail: security-discuss-help@community.apache.org