I'm really happy to see some great discussion on our response and the work on the wiki so far. I felt there were some repeated parts and it needed help with reordering, so I've created a copy as a sub-page with those major edits and additional information about the security team role. This is, I believe, just a submission we're making in advance of a pre-meeting so it doesn't need to be totally word-perfect, and I think it's still a level too detailed (I left a lot of the existing text in); perhaps it needs more of the "why is the ASF important, influential, and relevant" kind of elevator pitch.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530004 Regards, Mark On Sat, Jan 1, 2022 at 8:25 PM Sam Ruby <[email protected]> wrote: > First read: this is awesome > > Second read: nope, not particularly controversial, and even the areas > that are potentially controversial are adequately marked as such > > Third read: this concept may not match the intended audience. I had > to look up SDLC, but I'm certainly familiar with the concept of a > Software Development Lifecycle, but the person we send this to may not > be - their area of intelligence may be elsewhere. Actually, strike > that - is undoubtedly elsewhere. > > So, whether this content is a gold mine or gobbledygook is in the eye > of the reader. And, all things considered, I'm entirely OK with that. > As long as we don't overwhelm them, we can try multiple approaches. > > I took a stab at concatenating the input to date, and the results are > here: > https://cwiki.apache.org/confluence/display/COMDEV/White+House+Software+Security+Meeting%2C+January+13%2C+2022 > > I adjusted the formatting, fixes a few typos, and reworded a few first > person references. > > I'm actually very pleased with the results. In theory, the ASF links > at the top are all that one would need. In practice, I expect that > they will be skimmed and the reader will then proceed to the bullet > points and background reading which tends to be more focused on the > problem at hand. With that background, the links are re-introduced, > this time with relevant content surfaced to guide further reading. > > In any case, the content is now on a wiki - hopefully that will enable > greater participation. My only request is that anything beyond > wordsmithing and formatting be accompanied by a post to this mailing > list so that people tracking this content can follow along. > > - Sam Ruby > > On Sat, Jan 1, 2022 at 1:39 PM Phil Steitz <[email protected]> wrote: > > > > > > > > On 1/1/22 9:53 AM, Sam Ruby wrote: > > > Phil, I'm pleased to see that the links you curated are almost exactly > > > the ones I picked: https://s.apache.org/3vkpr. > > Yep. I was happy to notice that too :) > > > And I'll add a link > > > that we both missed: https://apache.org/ > > > > > > I'm not of the opinion that we should be creating new content for > > > background material, nor do we have adequate time to do so. But I do > > > take to heart the suggestion that these links should not be buried, > > > but rather put front and center. > > > > > > What do you think about adding the following > > > > > > --- > > > > > > The best place to get started to know what the ASF is is here: > > > https://apache.org/. That page is full of statistics, videos, and > > > links. > > > > > > The following links in particular are important background to this > discussion: > > > > > > * https://www.apache.org/foundation/how-it-works.html > > > * https://www.apache.org/dev/ > > > * https://www.apache.org/dev/pmc.html > > > * https://apache.org/security/ > > > * https://apache.org/theapacheway/index.html > > > > > > --- > > > > > > What still is missing is the concept of a "supply chain". Perhaps > > > something along the lines of the following, which applies to log4j but > > > also applies to much of what the ASF produces: > > > > > > * Software developed at the ASF is made available at no cost and > > > without warranty > > > * Commercial products may include this software without entering into > > > any form of contract with the ASF, or even notifying us > > > * End users may purchase these products but have little interest or > > > ability to apply fixes > > > > You are probably right, Sam, that we don't have time to develop and > > agree on "new content" for this. That is why I stopped short of > > volunteering. But this AM against my better judgement, I did some > > hacking. The idea is a bunch of little tl;drs decorated with links. > > The key supply chain concepts are in the how development works and how > > the software is incorporated bits. I think there are really three main > > suppy-chain related ideas that people need to get: > > > > 0) While I guess we may not all agree at this point that it works, our > > biggest defense against vulnerabilities getting introduced is eyeballs, > > which our open development process supports. Any interested human (or > > bot) can be a QC inspector in our direct contribution part of the supply > > chain. We have always welcomed this, especially when reports come with > > patches. > > 1) There is a natural nesting that happens as software dependencies > > propagate through applications. Addressing vulnerabilities in base > > level components (e.g. log4j) has a cascading impact. Unless and until > > all downstream systems have effectively automated build, test and > > deployment systems, this creates systemic risk which has nothing to do > > with OSS per se. In his original post, markt called this out, along with > > 2) End of life is an industry standard concept that we apply at the > > ASF. End of life means no more patches. End of life software running > > in critical systems is another systemic risk. > > > > OK, here is what I hacked in the wee hours last night. Could be best to > > just use as notes or ignore if others don't agree with the content. > > -------------------------- > > > > * Foundation organization and governance structure > > (https://www.apache.org/foundation/governance/) > > The ASF is an operating US 501(c)3 organization that supports several > > hundred open source projects. The operating part of the ASF is managed > > by the President, supported by the Treasurer, Vice Presidents, > > committees and third parties. The ASF board provides oversight for > > operating functions as well as ASF project communities. The Legal > > Affairs, Security and Treasurer departments report directly to the > > board, which means, for example that the Security team acts with the > > authority of the board. > > > > * How oversight works ( > https://www.apache.org/foundation/how-it-works.html) > > ASF projects are run by Project Management Committees (PMCs). PMC > > members review and cast binding votes on releases, nominate and vote on > > new PMC members and collectively manage community, security, trademarks > > or other problems. The PMCs act on behalf of the ASF when they cut > > releases. The PMC plays a key role in technical project oversight, but > > not the only role. The full project community contributes by working > > (creating and reviewing) patches and contributing to discussion. > > > > All ASF community members, including PMC members, officers and the > > board, participate in our communities as individuals, not as > > representatives of companies or other organizations. Some community > > members are paid by their employers to contribute to ASF projects but in > > their ASF work they are expected to act in the best interest of the > > community, exercising their own best judgement. Impact on project > > decisions is based on publicly earned merit which accrues to > > individuals, based only on their contributions at the ASF. > > > > * How development works (https://www.apache.org/dev/pmc.html) > > ASF projects don’t all work the same and the ASF does not prescribe any > > kind of SDLC for our projects. What we do require is that everything > > happens in the open: > > All bug reports are visible to all interested parties (with > > exception of reported security vulnerabilities, which are kept private > > until patched) > > All commits to project source code are tracked and visible to all > > interested parties > > All project-related discussion that can be public is public > > ASF projects differ in how they do things, but most have documented > > process for working bug reports, introducing new features and planning > > and executing releases. As new features are developed and bugs are > > addressed, code changes are made that will go into releases. Typically, > > proposed changes are submitted as “pull requests” (PRs) that explicitly > > describe how the source will change if they are applied. The original > > source, the PR and any changes that result from applying it are all > > publicly visible. Any interested party can comment on proposed changes > > and it frequently happens that performance, security or other issues are > > discovered in the open development process that creates and modifies ASF > > software. > > > > * How releases are versioned, validated and distributed > > (https://www.apache.org/dev/#releases) > > ASF software is distributed and meant to be consumed in the form of > > versioned releases. ASF PMCs have various ways of packaging software > > for distribution, but the core asset being released is always source > > code. Releases must be voted on by PMCs, who are responsible for > > validating release candidates (RCs). Most PMCs also make RCs available > > to the public prior to or during release votes. Library or > > infrastructure projects sometimes make backward-incompatible changes as > > they develop new versions of their software. Sometimes, a > > backward-compatible version of the software is added and maintained in > > parallel, but it often happens that the actively supported version is > > not backward compatible with an older version. When library or > > infrastructure components make backward incompatible changes, downstream > > users may have to make code changes to upgrade their applications. > > > > * How ASF code is incorporated in other software > > ASF software is used in running systems in basically 3 ways: > > 1. A distributed system includes a running ASF product (e.g. Apache > > web server) > > 2. ASF software is integrated with other software to build > applications > > When applications created in 2. are themselves used to create other > > applications, nesting happens, causing the impact of a vulnerability or > > incompatible change at the lowest level to have a cascading impact. > > When a new release is made available by an ASF project, downstream users > > need to minimally make configuration changes and test their systems. In > > case 2. above they typically have to rebuild and redeploy their > > applications. In nested situations, this often has to happen > sequentially. > > > > * How security reports are handled (https://www.apache.org/security/) > > The ASF encourages responsible disclosure of security vulnerabilities > > discovered in software managed by ASF projects. The ASF security team > > sets policy, maintains security contacts for PMCs and provides support > > for projects responding to security issues. Reporters are encouraged to > > use the designated security contacts to report vulnerabilities > > privately. PMCs are required to respond to security reports promptly, > > working with reporters to investigate and if necessary develop > > patches. The ASF Security team may assist the PMC in publishing a CVE > > once the vulnerability has been patched and a release containing the > > patch has been made available. > > > > * How end of support works > > Like all software products, ASF code lines go through a lifecycle the > > terminates in end of support. Typically, ASF PMCs communicate end of > > support dates for products or code lines with ample time (one year plus) > > for users to plan upgrades or find alternatives. Once communicated end > > of life dates arrive, the PMC is no longer expected or required to > > accept or apply patches to the end of life versions. This includes > > security patches against identified vulnerabilities. Therefore in some > > cases, when users who are depending on no longer supported versions of > > ASF software, a version upgrade will be required to obtain a fix of an > > identified vulnerability and that may require code changes to integrate. > > > > Phil > > > > > > > > - Sam Ruby > > > > > > On Fri, Dec 31, 2021 at 3:10 PM Phil Steitz <[email protected]> wrote: > > >> Thanks, Sam. I think the bullets below are good for the meat, but > based > > >> on David's summary of the CISA conversation and various public posts, > I > > >> think there is some important background / educational material that > we > > >> need to communicate. The points that Mark makes about the lack of > > >> "upgrade agility" across the supply chain are not obvious to people > who > > >> don't do this every day, which is pretty much 100% of the audience > > >> here. If what we are collectively trying to solve is a supply chain > > >> issue, we really need a better level set on how exactly the supply > chain > > >> works. We have a fairly nicely encapsulated piece of it at the ASF > and > > >> explaining how that piece works is good background and good context > for > > >> how "help" can meaningfully applied in our communities. It also sets > us > > >> up to ensure that the consequences of any external actions, regs, etc. > > >> on our part of the supply chain are understood. > > >> > > >> So I would suggest that the meat below follows a brief backgrounder on > > >> ASF structure, governance, release and security processes and > policies, > > >> emphasizing the points where we connect to different software supply > > >> chains and how we accept and manage security issues. Probably a lot > of > > >> that can come from existing web pages, e.g [0-3]. It is probably > also a > > >> good idea to ask Sally to help review any docs we provide that are not > > >> just links to the web site. > > >> > > >> The key thing to keep reminding ourselves is that a) the WH and other > US > > >> gov ppl want to act and b) their understanding of root causes and > > >> practical solutions likely contains large gaps that can only be > > >> addressed by getting a fuller understanding of how OSS is made, > > >> distributed, consumed and maintained. > > >> > > >> Phil > > >> > > >> [0] https://www.apache.org/security/ > > >> [1] https://www.apache.org/foundation/how-it-works.html > > >> [2] https://www.apache.org/theapacheway/index.html > > >> [3] https://www.apache.org/dev/ > > >> > > >> On 12/31/21 12:06 PM, Sam Ruby wrote: > > >>> In addition to the in-person meeting next month, we are invited to > > >>> send read-ahead material and there will be a brief phone call. Given > > >>> that the call will only last 30 minutes, I presume that call will be > > >>> consumed by introductions, logistics, and perhaps questions about the > > >>> read-ahead material. That call will be on Wednesday, so I would like > > >>> to send any read-ahead material that we might have late morning EST > on > > >>> Monday. > > >>> > > >>> My thoughts are to lead with a summary/bulletized version of what has > > >>> been discussed recently on this list, followed by actual pointers to > > >>> the original emails. Here's a first draft... additions/corrections > > >>> welcome, both to the bullet points and new posts (preferably to this > > >>> list) that should be added. > > >>> > > >>> Key bullet points > > >>> > > >>> * This will require collective action > > >>> o There are things we can do, both individually and together, > to > > >>> reduce the number of vulnerabilities. > > >>> o There are things, such as SBOMs, that can help identify what > is > > >>> affected once a vulnerability is found. > > >>> o Much of this is moot if patches are never applied. > > >>> * Volunteers/community/participation > > >>> o Out contributors tend to be seasoned software professionals > > >>> whose employers include ASF releases in their commercial > products. > > >>> o Our communities are healthy, open, and transparent. > > >>> o Companies an government agencies that want to help don't need > > >>> money or formal contracts to do so. Join our mailing lists, > > >>> review our code, contribute fixes. > > >>> > > >>> Background reading: > > >>> > > >>> * EO - Mark Cox - https://s.apache.org/3nctr > > >>> * SBOM - David Nalley - https://s.apache.org/hccur > > >>> * Applying updates - Mark Thomas - https://s.apache.org/5jqab > > >>> * Collective action - Phil Steitz - https://s.apache.org/ljzn0 > > >>> * Volunteers - Sam Ruby - https://s.apache.org/3vkpr > > >>> * Contributors/maintenance - Dominik Psenner - > > >>> https://s.apache.org/3lrk1 > > >>> * CISA - David Nalley - https://s.apache.org/1gr1c > > >>> * Get Involved - > https://www.apache.org/foundation/getinvolved.html > > >>> > > >>> - Sam Ruby > > >>> > > >> > > >> --------------------------------------------------------------------- > > >> To unsubscribe, e-mail: > [email protected] > > >> For additional commands, e-mail: > [email protected] > > >> > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > [email protected] > > > For additional commands, e-mail: > [email protected] > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: > [email protected] > > For additional commands, e-mail: > [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: > [email protected] > >
