Inline thoughts. On Tue, Sep 12, 2023 at 1:28 AM Jarek Potiuk <ja...@potiuk.com> wrote:
> > It's very important for us to focus our limited volunteer resources where > they will provide the biggest benefit to our users. I would never want > fussing with artifacts that users can and will reconstruct themselves to > take cycles away from > > * Clear and responsible disclosure and timely patching of our own > vulnerabilities > > +1 on the utmost importance of that. Funny thing is how big part of those > things we improved and addressed in Airflow with rebuilding and > restructuring of our Security team working hand-in-hand with the ASF > Security team (we have a presentation with Arnout sharing our lessons > learned there in a month at Community Over Code in Halifax) > https://communityovercode.org/schedule-list/#CY011. And I think the ASF is > already very good here with the current processes. Our lessons basically > show that carefully applying what we already have, deliberate focus on > making it an important aspect of the PMC work and improving tooling here - > and we are pretty much there as an organisation. If anything, possibly > incremental improvements, closer cooperation with the ASF security team, > sharing the lessons (as we do in Halifax) and possibly learning from others > (we got a fantastic experience with inviting an interested security > researcher to our team for example) is what we need. > > But ... it's not enough and it's not "either-or" IMHO. SBOMS/VEX are a way > to bring it to the next level (and something that soon will likely be > mandated by CRA and other regulations). > Very much looking forward to your talk. I think we're still at a distance from regulations requiring SBOMs/VEX etc of the ASF - but I acknowledge by dint of my location I'm US-aware rather than EU-aware. > > * Upgrading dependencies to address vulnerabilities reported against them > > Yes. Providing that we know we have to upgrade. And we have a way to track > their vulnerabilities and vulnerabilities of their dependencies and so on. > First, we need to know that the dependency we are using have > vulnerabilities or maybe that the dependencies of our dependencies have > some vulnerabilities. Are we tracking that today? Do we know which > dependencies we should upgrade proactively? Please raise a hand who does. > > We have no time for that - we have (as you mentioned) limited time, so we > won't be able to monitor and upgrade all of that ... unless we automate it > ... And there are various ways of dealing with it. Dependabot is one thing, > In Airflow we have our own mechanism for doing such upgrades in bulk. But > it all is based (under-the-hood) on discovering and analysing what our > dependencies and dependencies of our dependencies etc. are and what > vulnerabilities they have and whether they affect us. Of course there are > some tools for that, but they all ultimately depend on everyone in our > ecosystem generating and publishing (somehow) dependency information. Some > of that might be (and is) automatically retrieved via various tools > analysing dependency requirements etc. And that is cool. > > But some of those are fundamentally flawed. For example when your java > library uses vendored in code, probably you are the only one to know it. > See for example this issue https://github.com/pypa/pip/issues/12259 - > where `pip` has vendored in the vulnerable `certify` library. No tool in > the world would actually detect it in a "reliable" way. Some expensive > tools might guess it by analysing source code (BlackDuck) but they would > also produce a huge amount of false positives (my experience from the past > of using it). And most free tools will simply look at the usual suspects - > requirement files etc. > Agreed. Though, I've seen very little active conversation in the SBOM space on this (code copied into a source tree). Effectively what's needed is for the elements we put in a NOTICE file today to be turned into a machine readable format that is then pulled into the ten-a-penny dependency-build-plugin and merged with the dependencies. Now that would be a good thing for us to work on - a cross project standard for ASF projects to identify 'alien' content that is copied into the source tree. Thinking Java - I get to wade through Maven jars in my dayjob, bundling/shading and maven plugins that just throw all the dependencies into the '.jar' are an enormous waste of energy. That's where our SBOM energy should start (says my pain). What's in this massive jar: https://repo1.maven.org/maven2/org/apache/tika/tika-app/2.9.0/ > > But if `pip` published SBOM with that information (and you would know where > to find that information) - that would be an easy, automatically > consumable way for the users of `pip` to find out what they are depending > on. Moreover (same issue) it turned out that even if certify is vendored > in, `pip` is not affected by this vulnerability. This particular issue has > led to a long discussion and maintainers had to spend considerable effort > in explaining to concerned users who found out that certify is actually > used internally and that it is in the vulnerable version, `pip` itself is > not vulnerable. This is what VEX files are automating. Together with SBOMs, > there is a way to communicate to the users "Hey we know this and that > dependency is vulnerable, but we are NOT affected, so you can safely use it > (and BTW it's difficult to upgrade for us so we are not going to upgrade it > soon". > Big +1 for VEX; opinionated advisories are a grand direction and VEX sounds more useful today than SBOMs. > > * Making downstream patching as easy as possible for users (e.g. > back-porting fixes) > > Absolutely. Back-porting is one things but it is often difficult and > extremely time consuming, but there are other ways - for example strictly > implementing SemVer and making it easy for the users to upgrade to released > versions (and publishing the VEX files so you are not flooded with "you are > using this vulnerable version of x, you must upgrade it NOW" when you are > not affected). And again - it's not either-or. It's needed and important. > But IMHO not enough. > I'd also like to see standards in terms of which versions we support. Think of it as the Attic's tendrils reaching out - which versions of our projects are EOL and which are not, and why is that not exceptionally easy to identify? Which versions are critical-fixes only? And why don't we have a common language for how we go from "Not ready for Prod" to "Choose this" to "Critical fixes only" to "EOL"? Again - looking forward to Halifax :) Hen