In general: keep your dependencies up to date. Keep the DEPENDENCIES file in mind. Ask committers for help, if you
don't have one in your team.
Specifically Docker base images: If dependabot suggests to upgrade the base image to a new major library version,
that you do not support. Ask a committer to tell dependabot to ignore the dependency
Specifically Chart Releaser Action: Should not be an issue, but we can investigate if the upgrade would raise
issues (1.4.1 to 1.6.0 in this case)
Collaboration call for shared Ownership for Release 24.05 we will have a tandem mode for the upcoming release and searching for responsible through the mailing list
SAST: CodeQL transition is ongoing, PRs to add corresponding workflows is ongoing. Veracode license will expire at the end of March, so everyone is encouraged to review their workflows to ensure a timely transition to CodeQL.
DAST: Invicti license will expire at the end of August and already exceeded the website limit. There will be no DAST tool required for the next Quality Gate.
Secret scanning
Gitguardian is currently set up, but Gitleaks is a potential successor.
Testing of Github secret scanning is still in progress.
TRG 8.0 has been published as a draft, adjustments as PR are warmly welcome.
Role of the committer is being discussed, it will be presented in the next committer meeting.
Basic role descriptions come from the Eclipse Foundation, but we want to specify in Tractus-X
what else can be expected from a contributor,
commiter and project lead.
Association release process and Eclipse Tractus-X needs to be aligned as the first is managed by
the association and the second should be driven by the community.
We should align on how and where a migration documentation should be created for products.
This would ensure that upon Breaking Changes the upgrade processes can run smoothly with
a guide available for everyone. The guide could include property, configuration, API changes
and everything else that would affect the upgrade process from and old version to the new.
A draft will be available on a working model that could be implemented by the products soon.
A TRG could include information on where these guide should be located and in which format.
An overarching issue for tracking the tool shifts was discussed, as it is necessary for proper planning by teams.
Teams need to estimate efforts to adjust Github workflows
The PR for the new Security TRG was discussed, which includes a new requirement of remediation of findings with medium severity, but not for the 25.05 release.
Concerns were raised about the need for additional planned team resources for triaging these issues, and it was suggested that the TRG should be finalized and teams made aware.
What are best-practices for scheduling security tools Action workflows, with every PR or another frequency?
The TRG claims at least once, this is mandatory baseline for all.
Best practice is more frequently, recommendations differ per tool (e.g. secret scanning for every PR, dependency scan on a weekly basis).
The trigger will be on push + on pull + scheduled - frequency depends on repositories activity, so the team has to decide.
Best practice recommendations will be published in the sig-security repository.
Still looking for volunteers to work on QG reviews together with the system team
Goal is to spread knowledge on how TRGs are checked
Especially interesting for committers, that already know they will stay post consortia
Preparing an open description on our release process. Feel free to comment any suggestion or important topics, you think should be covered on this draft
Markdown linting will again be enabled for KITs. Findings will be collected as issue per KIT
OpenAPI plugin for docusaurus will be removed
OpenAPI definitions will be pushed to SwaggerHub. User credentials available as org secrets
Ongoing discussions: Some definitions might be published through standard and therefore out of eclipse-tractusx
