Brian,
On 10/15/24 10:33 AM, Brian Demers wrote:
Re: .well-known/security.txt
TL;DR a common security.txt template would be nice
It might be nice to generate these based on data in the project's asf.yaml?
(granted that's an implementation detail).
One of later changes in the RFC was the requirement for the
"expires" filed, it would nice to see recommendations around this (less
important if this is generated regularly)
Similar with the "Contact", field, Shiro's security.txt [0] only has a
single entry, but I'm guessing _should_ be both the project's mailing list
and `secur...@apache.org`, (though I'm not sure this matters given how the
mailing list alias work)
[0] https://shiro.apache.org/.well-known/security.txt
This should really be PGP-signed by someone in the ASF web-of-trust.
Otherwise, the security.txt "standard" is really super basic. I was
surprised to see so many commonalities between the Shiro and Tomcat files :)
-chris
On Tue, Oct 15, 2024 at 7:32 AM Mark J Cox <m...@apache.org> wrote:
On Tue, Oct 15, 2024 at 1:14 AM Jarek Potiuk <ja...@potiuk.com> wrote:
...
and I know Arnout is working on showing such an assessment for the ASF
projects - and exposing it, so maybe that should be the starting point.
Maybe Arnout, you can share what you have now ? And maybe we could work
together on making it available as "standard" information available to
our
PMCs ?
We're currently capturing health information as issues in a private github
instance (you and the security committee have access) and using a script to
parse those open issues to provide the commentary that will go into the
board reports. For the October board report we provided the output to the
board but it's marked as private this month, as we wanted to give ourselves
time to make sure none of the projects listed there were surprised (or had
corrections). For November and going forward the report will be split into
a section that is recorded in the public available minutes, and a private
section that can contain vulnerability-specific information (for example
stating details of not-yet-public issues and plans to address them). We
can also parse the labels of the issues to come up with a dashboard, and we
do plan to expose that data somewhere, probably an automated web page, so
that users of Apache projects can get an idea of the security health.
Individual PMCs are reminded on a frequent basis about their unfixed
security issues, and part of our new process is to parse the red/amber
health projects more often so a PMC should have direct contact from the
security team and it will be clear what state they are in (and how to get
better).
But unlike OpenSSF scorecards which are designed to be fully automated, the
data we are collecting is entirely manual and can't be automated. It's
more like a set of red flags combined with the position of the project in
our new escalation plan.
Regards, Mark
ASF Security
---------------------------------------------------------------------
To unsubscribe, e-mail: security-discuss-unsubscr...@community.apache.org
For additional commands, e-mail: security-discuss-h...@community.apache.org
