On Sun, Jan 2, 2022 at 1:36 PM Mark J Cox <[email protected]> wrote: > > 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
There is an advantage at times to repetition, but at the moment, I will suggest that an executive summary be added to the beginning. Shoot for three bullets (one sentence or so each), with a max of 5. And try to make it so that if they only read the summary, they have been exposed to the important points. The danger is that the decision maker hands this to somebody to summarize. We want to be ones to provide the summary. I think we have the raw data. I'd suggest that you are in the best position to pick out the 3-5 points to highlight. > 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. I added back in the link to www.apache.org. I think that should suffice. It does a better job than we can do, and doesn't distract from the content. > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530004 > > Regards, Mark - Sam Ruby > 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] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
