Attendees: Joakim Bech(Linaro), Don, Abhishek Pandit(Arm), Anton Komlev(Arm), Dan Handley(Arm), Kevin Oerton(NXM Labs), David Brown(Linaro), Julius Werner(Google), Andrej Butok(NXP), Eric Finco(ST), Michael T(Renesas)
Minutes:
Security Incident Reporting Review
Reference Joakims email thread
Joakim shared the background. Working to simplify. Walked thru a sample incident process spreadsheet.
DB: How consistent in alerting additional Stakeholders?
Joakim: reference Phabricator page to answer the question.
Joakim: Process requires discipline. Shared checklist.
Each issue would have its own checklist.
KO: Looks good and provides the picture we need
KO: Why manual process?
JB: See checklist - must add dates
DanH: New tab for each checklist may be hard to sustain.
KO: Automation would be nice
AP: What is this solving?
KO: From Technical oversight, this provides a high-level view of security robustness and responsiveness to issues. May be a useful mgt tool to understand security state and velocity is sufficient.
DB: With Zephyr, a checklist for each issue has caught things that would have been missed, like publishing to MITRE.
DanH, AP: Agree checklists seem useful.
AP: Doesn’t include effort. What metric is needed?
DB: Need a start and an end, which doesn’t happen in this.
MT: Renesas uses Jira. Excel is tough - not scalable and can’t export
AP: What is the use of date for each transition?
DB: Checklists, and states in Jira. Jira is not trivial either and must be tuned when changes are made. Clickup or Airtable might be good choices. Scriptable is helpful. Not free solutions.
KO: Air table is $60 / month. Development/maintenance is the real cost.
DanH: Corner cases are abundant and can skew statistics.
DB: Current sheet is a report, the data is the dates.
AP: Only stats that matter is when Opened and When closed. If lock-on purpose, then can decide what data is needed.
DB: On zephyr, patches are done by others rather than the security team, which makes it difficult. What happens when a 3rd party comes in?
DanH: Could be a case but hasn’t happened.
Agreed to table this and discuss again in a month
Phabricator Deprecation:
Noted raised and not discussed. Will discuss later
TF-M Release cadence change
Anton: From 4 to 6 months. Minimizes overhead associated with releases
KO: Keeping the window open allows better synchronization.
Anton: Each project is different. Smaller windows have a better chance to overlap.
EF: How aligns w/ MCUBoot?
Anton: No formal plan there, we pick it up asap.
EF: 2 versions in a time window. Make sure MCUBoot release is done 6 weeks before, for example, so can be merged in
Anton: This aligns with the purpose of this proposal. TF-A also has 6 months schedule.
AP: MBed TLS starting open tech Forum.
AP: ADAC repo - top-level repo now available. Expect a tech talk in the future
AP: Roadmap discussions: None this month as it was covered last month, plan to do every month. If can have lightning talks from Member reps on how they’re using TF.org projects and are public. Still deciding if useful and how to organize?
KO: A sense of how this is getting leveraged is the ultimate end goal. A google project w/ BOM is being tracked for security issues that impact other projects.
AP: Feel free to provide Abhishek feedback outside this forum
AP: Funding approval for Open CI. All aware
DonH: FYI includes reduction of Community Mgr to 0.3 to maintain a healthy surplus. Also, the majority votes are in and it has passed.
Joakim: Can now compile OP TEE TA’s in Rust