I would like clarification on how the Trusted Firmware bug bounty program handles researcher priority when submissions remain with Intigriti for an extended triage period.
Intigriti triage can currently take approximately one to two months. During that period, it is possible for Arm or the Trusted Firmware project to independently discover, investigate, or fix the same vulnerability before Intigriti completes triage and forwards the submission.
In that situation, what point in time is used to determine whether a report is considered “already known” or a duplicate?
Specifically, is priority determined using the researcher’s original submission timestamp, or the later date on which Intigriti completes triage and the report reaches Arm?
If a researcher submits a vulnerability first, but Arm independently discovers or fixes the same issue while that submission is still awaiting Intigriti triage, does the researcher retain priority and bounty eligibility?
Conversely, if Arm considers the issue to have already been known before the researcher submitted it, what timestamp or internal record is used to establish that the issue predates the submission?
Finally, does Arm PSIRT or the Trusted Firmware security team receive any information about submissions while they are still in Intigriti’s Triage state, or are reports only passed to Arm after Intigriti completes triage.
Best regards,
Guled
Dears,
Writing to inform you that we're going to cancel the upcoming TSC meeting scheduled for this Thursday as several people are on summer break. We will reinstate the series starting from the September meeting.
@Shaun Longhorn<mailto:shaun.longhorn@linaro.org> can you please cancel the August meeting?
Thanks,
Antonio
Sent from Outlook for Mac
Hi all
Sorry for the late notice, but today's TSC meeting is cancelled. We don't have a strong agenda and we expect low attendance anyway.
Regards
Dan.
Hi all
The agenda for this week's TSC meeting so far is:
*
Firmware-A roadmap (TF-A, TF-RMM, Hafnium)
*
TF-M roadmap
*
TF-PSA-Crypto roadmap
Let me know if you have any other topics.
Regards
Dan.
Hi all
I've sent this to what I hope is a representative subset of TrustedFirmware.org project maintainers. Feel free to forward to others you think should be included.
I'm writing to gather maintainer feedback on a proposal for TrustedFirmware.org to have a policy on the use of AI-assistants in code contributions. Several other open-source organizations already have their own policies. Attached is the current draft of that policy, which is based on the Linux Foundation and Apache Software Foundation guidance. This has been discussed at the TF.org board and more recently, the TSC (see minutes here<https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.o…>). Eric Finco @ ST had 2 pieces of feedback to this, the 2nd of which prompted me to seek this wider input. To summarize that feedback:
1. Eric would like all contributions that use AI assistants to explicitly attribute the tool(s) used in the contribution for transparency reasons. The counter feedback is that this might be onerous to generate (especially if a tool has a complex backend) and there is no clear use for that information.
2. Eric would like the policy to apply to all TrustedFirmware.org projects, rather allowing projects to develop their own project-specific guidance (as per the current draft).
Some of this might require more interaction discussion. My plan was to invite you all to a future TSC meeting (perhaps in September) to discuss further. I'm happy to take feedback on the policy, Eric's feedback or the process to handle this. Feel free to reply to this email (to all or just to me), or just wait for that TSC meeting.
Best regards
Dan.
Hi all
Let me know if you have any topics for Thursday's TSC meeting. So far I have:
*
Integration of PSA-Crypto and Hw Accelerator driver support in TF-A (proposed by ST).
*
Project health discussion, given increasing maintainer bandwidth constraints.
Regards
Dan.
Hi all
Below are some edited AI notes from today's meeting:
Present:
Eric Finco (ST)
Antonio De Angelis (Arm)
Dan Handley (Arm)
Kamlesh Gurudasani (TI)
Frank (Nordic)
David Brown (Linaro)
Joanna Farley (Arm)
Dominik Ermel (Nordic Semi)
Quick recap
The meeting focused on several key topics related to Trusted Firmware development and project policies. The group discussed changing the "co-developed by" tag format in the AI-assisted contributions policy<https://www.trustedfirmware.org/aipolicy/> to align with the new Linux project guidelines<https://github.com/torvalds/linux/blob/master/Documentation/process/coding-…>, with Kamlesh noting that some TF-A patches<https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/39036> had already used the "co-developed-by" tag.
The team reviewed a Zephyr interpretation<https://docs.zephyrproject.org/latest/security/standards/cyber-resilience-a…> of the CRA (Cyber Resiliency Act) requirements and their implications for vulnerability handling and SBOM generation, though David emphasized the importance of avoiding legal advice in the documentation unless it's been reviewed by a lawyer.
Antonio presented options for creating a separate PSA crypto driver repository on GitHub, with Frank explaining that the main driver was familiarity with GitHub for vendors, though licensing concerns were raised.
The conversation ended with Dan advertising a new Confidential Compute Working Group<https://corecollective.dev/working-groups/> at CoreCollective that would kick off the following week, initially focusing on CCA reference SW roadmap and CCA attestation enablement.
Next steps
*
Dan: Send an offline message to the group proposing the change to the "co-developed by" tag in the AI policy and proceed with the change if there are no objections.
*
Dan: Run the proposed tag change by the maintainers and ensure everyone who is using the tag is notified if the change proceeds.
*
Antonio (and relevant team members): Discuss further with Gilles and the PSA-Crypto team regarding the creation and use of a new GitHub repo for PSA crypto driver prototyping, including considerations around licensing, building, and testing.
Summary
AI-assisted Contribution Policy Discussion
The team discussed changing the "co-developed by" tag in the AI-assisted contributions policy<https://www.trustedfirmware.org/aipolicy/> to align with the new Linux project guidelines<https://github.com/torvalds/linux/blob/master/Documentation/process/coding-…>, which uses an assisted-by tag with a specific format. The Linux policy is otherwise well aligned. Attributions are optional. Dan proposed sending an offline notification about the proposed change since no objections were raised during the meeting. Kamlesh pointed out that some TF-A patches<http://some%20TF-A%20patches> had already used the "co-developed by" tag. The team agreed this is just for audit purposes so there should be no need to change existing code.
CRA Compliance Documentation Discussion
The team discussed a Zephyr analysis<http://Zephyr%20interpretation> <http://Zephyr%20interpretation> of the CRA and its implications for open source stewardship, with David explaining that that document had been reviewed by lawyers since it contains legal advice about CRA interpretations. Eric proposed using future funding to prepare materials for due diligence, but the group agreed to focus on factual statements about their current practices rather than making interpretive claims about CRA compliance. David raised concerns about the target audience for additional compliance features, noting that many Trusted Firmware members are SOC manufacturers rather than device vendors who would face direct CRA compliance requirements. The discussion concluded with questions about due diligence requirements and vulnerability reporting timelines, which David noted might be more aggressive than current practices.
PSA Crypto Repository Planning
The team discussed creating a new GitHub repository for prototyping PSA crypto drivers, with Frank explaining that the main reason was to align with most vendors' existing GitHub workflows. Antonio raised concerns about licensing issues and building/testing processes for the new repository. The group also learned about an existing PSA crypto API repository<https://review.trustedfirmware.org/plugins/gitiles/shared/tf-psa-crypto-dri…> on Gerrit, but noted it doesn't address licensing requirements for code hosting. Dan noted the existing PSA Crypto API GitHub<https://github.com/ARM-software/psa-crypto-api> doesn't look suitable for code sharing as there is no license information.
AOB
The conversation ended with an announcement about a new Confidential Compute Working Group<https://corecollective.dev/working-groups/> kickoff planned for the following week.
Please note the below is a combination of AI generated and my own notes. Please find the slides I showed attached.
Regards
Dan.
Meeting summary
Quick recap
The meeting focused on several key topics related to Trusted Firmware and security initiatives. Dan provided updates on the PSA specification governance, emphasizing the goal to maintain long term momentum with wider participation. The discussion then shifted to the TF bug bounty program, which has seen a significant increase in submissions, leading to concerns about maintainability and the use of AI tools in submissions. Dan highlighted the challenges faced in managing the volume of reports and the need for more CVEs, which has been delayed due to responsiveness issues with Mitre. The group also discussed the launch of Core Collective, a new collaboration platform backed by Arm and Linaro, and its potential role in supporting various projects, including Trusted Firmware. David raised questions about the organization of working groups within Core Collective and its potential impact on existing project structures.
Next steps
* Dan: Send meeting slides to attendees after the meeting.<https://tasks.zoom.us/?meetingId=WM9WhRFeRT2Qu%2BUdFs2eyA%3D%3D&stepId=2ebd…>
* Dan: Pass on feedback and concerns about the bug bounty program to the Arm PSIRT team.<https://tasks.zoom.us/?meetingId=WM9WhRFeRT2Qu%2BUdFs2eyA%3D%3D&stepId=2ebd…>
* David and Dan: Discuss offline the possibility of using AI/automated tools for internal bug triage and analysis, and potentially test such tools.<https://tasks.zoom.us/?meetingId=WM9WhRFeRT2Qu%2BUdFs2eyA%3D%3D&stepId=2ebd…>
* David: Set up a call with Grant to discuss Zephyr backporting/LTS funding and Core Collective project structure.<https://tasks.zoom.us/?meetingId=WM9WhRFeRT2Qu%2BUdFs2eyA%3D%3D&stepId=2ebd…>
* Dan: Lead or co-lead the confidential compute working group in Core Collective and organize a discussion in the next month to define scope and membership.<https://tasks.zoom.us/?meetingId=WM9WhRFeRT2Qu%2BUdFs2eyA%3D%3D&stepId=2ebd…>
Summary
Present
Ben Vogel (QTI)
Eric Finco (ST)
David Brown (Linaro)
KangKang (FutureWei)
Michael Thomas (Renesas)
Julius Werner (Google)
Kamlesh Gurudasani (TI)
Andrew Davis (TI)
Dominik Ermel (Nordic)
Joanna Farley (Arm)
Dan Handley (Arm)
Zephyr Long Term Support (LTS)
David explained how Zephyr is trying to change its LTS frequency from 5 years to 3. To date Zephyr has been pulling main branches from TF projects, which isn't great. Now plan to pull in TF LTS branches and if they go out of date for Zephyr, we can discuss how to address it in a public forum, maybe at CoreCollective. There was some discussion on there being a Zephyr Working Group (WG) at CoreCollective, but Zephyr has wider scope than just Arm architecture platforms. There is an Edge WG, which includes part of Zephyr in its scope. Joanna mentioned how TrustedFirmware-A related projects are released together, which helps to managed dependencies. David countered that this is harder across project ecosystems with different governance - one has to go first. Michael also mentioned difficulties managing versions in their product because some dependencies are using older versions of TF projects; they have to fix the dependencies themselves.
PSA Specification governance moving to Global Platform (GP)
The group discussed changes to the PSA specification governance, with David agreeing that making the specification more broadly applicable beyond ARM was a good idea, particularly given its use in Mbed TLS and other areas. Dan confirmed that the copyright and licensing would remain unchanged, and Andrew Thoelke would continue to manage the PSA APIs as working group lead. The discussion addressed concerns about implementation in TF, which would not change, and David suggested that PKCS11 could potentially be replaced in the future.
The team discussed the progress and potential for moving PSA API and FF-M specs to GP, though the timeline remains unclear.
TF Bug Bounty Program
Dan shared updates on the TF bug bounty program, which launched in December and has seen a higher volume of reports than anticipated, leading to changes in the program's rules to prevent automatic suspension due to budget constraints. Despite these challenges, the program continues to receive submissions, with 103 reports in March alone, raising concerns about the sustainability of the workload for maintainers.
The team discussed security vulnerability handling across different projects, with Dan noting that Mbed TLS and OP-TEE are experienced in managing high volumes of security issues, while TF-A has been more challenging due to lower volume historically. Dan mentioned that Hafnium is not yet live in the program but it probably should be added soon. Kamlesh inquired about TF-A bug types, clarifying that while platform-specific issues are out of scope, some may still be considered if reproducible in a platform context. The team also discussed the increasing use of AI tools in bug submissions, with Dan estimating over 90% of submissions now using such tools, and Kamlesh raised questions about bug bounty program payouts and effectiveness. David suggested using AI tools to analyze and triage bug reports, which could be a potential approach given the high volume of submissions. Eric asked whether the 10% rate of valid reports is the same across projects. Dan said we don't have that data but we expect so.
The team discussed challenges with AI-generated bug reports, noting that while some reports contain valid vulnerabilities, others are of low quality or incorrect. David and Dan agreed to discuss the issue offline, as they are two of the people managing the tools. Ben shared that the curl maintainer had to cancel their bug bounty program due to overwhelming low-quality submissions. The team considered implementing an invitation-only bug bounty program with a limited number of high-bounty issues to reduce AI submissions. Dan mentioned that the Intigrity and Arm PSIRT are currently filtering out most AI-generated reports, with only a few requiring deeper inspection.
CVE Allocation Challenges
The group discussed the delay in receiving CVEs from Mitre, which is taking over a month for allocation, making the process increasingly cumbersome. David and Dan discussed the admin challenges of the security teams generating CVEs themselves, highlighting the need to justify the training time and costs for already-stretched teams. They considered options such as using the existing TF budget surplus to cover training for someone to handle the task, though this could risk affecting other work.
Core Collective
Dan mentioned that Core Collective, launched by Linaro with backing from Arm, is a new collaboration platform that is free to join and has a governance structure similar to Trusted Firmware, but it is not intended to replace it. Dan clarified that the confidential compute working group is still in the planning stages, with Dan set to lead discussions on its scope and membership in the coming month.
Hi all
I only have a few small topics for today's TSC so I'm not expecting a long meeting (yes, I know I've said that before). Please let me know if you have anything else.
*
PSA Certified API spec governance.
*
TF.org CVE allocation
*
CoreCollective CCA working group
Regards
Dan.
