I really like the idea of having a rotation support system for the security team. It is rather important for a couple of members to have this skill as their forte because security is generally not a common area of expertise in my experience as an engineer.
It is often looked at as "boring" or "hard" by most members. But, it would be a great opportunity to introduce this process so that more people can get engaged and feel being a part of something "big" and "significant". I agree with Dennis' idea of having a shadow period to understand under a senior member who has done it before. This will not only enhance the process but also be a "training" period for interested folks. Thanks & Regards, Amogh Desai On Tue, Dec 5, 2023 at 12:58 AM Jarek Potiuk <[email protected]> wrote: > Just to add on it - yeah - formal "shadowing" is not needed, we are > friendly and welcoming and I can't imagine the rotation will be "big" - I > think quite a few past team members will have to stay in the team every > rotation to make sure we keep the experience :). > > Maybe just to add what security team participation is: > > * responding and communicating with security reporters (I mostly do that > now based on our discussions - but we are preparing some "canned" responses > based on past ones and it's mostly to make sure that we keep them in the > loop and communicate properly) > * recording the issues and extracting important information in form of > Github Issues following certain template we have (this might soon be gone > if we manage to switch to private Github security reporting) > * triaging the issues - reproducing (we only accept issues that have > reproducible steps in general) and confirming the vulnerabilities > * participating in discussions and assessing if the reports are "valid" > issues - based on both, discussion, (yes) googling or stack-overflowing to > learn - but also trying to apply common sense > * voting in case we cannot reach consensus in the discussion > * volunteering to solve issues and do it (identifying and reaching out to > others privately to ask them to help - if expertise is needed - with the > consent of other team members) > * proposing "common" improvements possibilities if we see that we should > solve "bigger" problem rather than individual issues > * discussing on the process and improvements for the whole team, > volunteering to implement them maybe > * helping release managers to describe the impact of the issues (sometimes) > > Sounds a lot but it really occasional involvement - I think we are in a far > better place than we were few months ago where the sheer volume of the > issues was quite overwhelming > > J. > > > On Mon, Dec 4, 2023 at 7:42 PM Ferruzzi, Dennis > <[email protected]> > wrote: > > > I don't know that we'd need to make the shadow period too formal, we all > > come from diverse backgrounds. One of the reasons I didn't step up for > > the "full-time" position is that I have no real background in the > security > > side of things and I didn't want to be a drain. But I'd consider a > > rotation, with the understanding that I'm definitely there to learn and > > won't likely be good for much more than chasing down leads someone else > > comes up with. I can google and stack-overflow with the rest of them, > > given some direction. :P > > > > > > - ferruzzi > > > > > > ________________________________ > > From: Aritra Basu <[email protected]> > > Sent: Monday, December 4, 2023 5:40 AM > > To: [email protected] > > Cc: [email protected] > > Subject: RE: [EXTERNAL] [COURRIEL EXTERNE] [PROPOSAL] Security team > > rotation introduction to our process > > > > CAUTION: This email originated from outside of the organization. Do not > > click links or open attachments unless you can confirm the sender and > know > > the content is safe. > > > > > > > > AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. > > Ne cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne > pouvez > > pas confirmer l’identité de l’expéditeur et si vous n’êtes pas certain > que > > le contenu ne présente aucun risque. > > > > > > > > I think overall it is a great idea to slowly bring in more people into > > rotation. It should help with adding redundancy and help prevent burnout > > for the people who are doing it now. > > > > I would propose perhaps a gradual introduction via a brief shadow period > > where a new member would monitor the happenings but not partake in > decision > > making and once they are done with the shadow period they take on full > > responsibility. > > > > -- > > Regards, > > Aritra Basu > > > > On Mon, Dec 4, 2023, 6:20 PM Jarek Potiuk <[email protected]> wrote: > > > > > Hello everyone, > > > > > > *TL;DR; *I have a proposal of refinements we can apply to our security > > team > > > and I am looking for comments and feedback (PR is out there in [1]). In > > > short I am proposing that we introduce rotation of the security team > > > members, so that we can avoid burnout, give a chance to others to learn > > > about security and make security team membership effectively temporary > - > > > which might help people with their decision to sign-up for a few months > > to > > > learn new skills and see how it works. > > > > > > *Context:* > > > > > > It's been quite a few months since we introduced the security team. > see > > > that as a pretty successful change we implemented. I've given a talk > [2] > > > about it together with Arnout from the ASF Security team. But we can > > always > > > improve and iterate on the idea and I think rotation is a good idea for > > the > > > team to continue doing a great job and to bring more people in the > realm > > of > > > security. > > > > > > *Quick summary of where we : * > > > > > > * From > 20 issues in March, some of them > 150 days old, we are down > to > > > literally reported 2 (!) issues not being addressed yet (few weeks old > > and > > > we target to close them in the upcoming 2.8.0) > > > > > > * We introduced and iterated on both our Security Model [3] and > Security > > > Policy [4] - some of that is still to be released in 2.8.0 release > > > > > > * We have successful cooperation with Kei - the security researcher > that > > > brought a wealth of great insights and we've learned a ton from him and > > how > > > to approach security handling. > > > > > > * Thanks to funding 4 of the PMC members got from Sovereign Tech Fund > we > > > were able to also address a lot of potential (and real) threats in our > > > release and build process as well as improve it and harden it - and in > > the > > > near future also expose SBOM and better vulnerability exchange > > information > > > to Airflow users > > > > > > * As a new "ASF Security Committee" member - I already used experiences > > > from our team setup to help other projects to build their own > > > processes (somewhat competing with us "Apache Dolphin Scheduler"). > > > > > > *My personal view:* > > > > > > I think being part of the security team is a fantastic learning > > > opportunity. Security is becoming more and more important in Software > > > Development - we are at the verge of regulations that will change a lot > > > when it comes to approach to security issues, vulnerabilities, > > > vulnerability exchange, upgrading software and a lot more. > > > > > > This is an important experience and it's useful to have security-focus > > and > > > security experience/skills in the future software development industry > - > > > both from technical skill level but also process-wise. > > > > > > The rumour is that the CRA (the Cyber Resilience Act) that is about to > > > regulate security approach for software development in Europe has just > > > completed the intra-EU-policymakers negotiation phase and it already > > took a > > > final shape. It looks like it is actually very pragmatic and good for > the > > > Open Source community at large, as they seem to address literally all > the > > > concerns we raised seeing some initial versions of those regulations). > It > > > will still, however, mean that our processes have to be sound - and it > > also > > > seems that we in the ASF and Airflow particularly are well ahead of > > > everyone else and it's us who will be setting the "golden standards" or > > how > > > things should be done. > > > > > > There are very few people out there who could say they have "a real, > > proven > > > experience" with handling well established security processes in > > > Open-Source software, and I think it's good to have more people exposed > > to > > > it, and it's also good for the people to gain the experience (of course > > if > > > they are security-minded and they do not see it as "boring" - which > many > > > people do). > > > > > > Looking forward to comments/feedback. Do you think it's a good idea in > > > general? > > > > > > J. > > > > > > [1] PR: "Add security team rotation proposal to our security team > > process" > > > https://github.com/apache/airflow/pull/36049 > > > [2] {Presentation: "Lessons Learned: Improving the security process of > an > > > Apache project" > > > > > > > > > https://docs.google.com/presentation/d/1EIw4_NHI34v-9KzRDqFi7TS8Pn-O3DgUmjuKqlbghZU/edit#slide=id.p > > > [3] Airflow Security Model > > > > > > > > > https://airflow.apache.org/docs/apache-airflow/stable/security/security_model.html > > > [4] Airflow Security Policy > > > https://github.com/apache/airflow/security/policy > > > > > > J. > > > > > >
