> One of later changes in the RFC was the requirement for the "expires" filed,
That's one of the thing you can specify in machine-readable OSSF Security Insight specification: https://github.com/ossf/security-insights-spec/blob/main/security-insights-schema.yaml#L15 On Tue, Oct 15, 2024 at 4:35 PM Brian Demers <bdem...@apache.org> 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 > > 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 > > >
