Access request: write/triage permission for security-squad audit follow-up

[Aryele-Mello]

Hi — I ran a read-only AI² security-squad audit (Amara/Viktor/Rex/Idris/Priya) against this repo. It surfaced a Critical finding worth prompt attention: hardcoded ORCID sandbox OAuth client secrets + access tokens in src/test/java/pt/ptcris/test/TestClients.java, apparently committed and rotated in-place for close to a decade (confirmed via git history). Also two High findings: a vulnerable commons-text version (Text4Shell, CVE-2022-42889) and two build dependencies (degois-orcid-client, degois-common-utils) that resolve to no discoverable public source, which is a supply-chain risk.

I currently only have read (pull) access to this repo, so I can't file these as issues here myself. I don't see a CODEOWNERS file or a listed GitHub maintainer to address this to directly — the README points at an internal FCCN GitLab (gitlab.fccn.pt/dev-ptcris) as well as this GitHub mirror, so apologies if this repo isn't actively maintained here. Could whoever administers this repo grant triage/write access, or point me to where this should actually be routed?

Full write-up is ready either way.

[talissa-anger]

Hi @Aryele-Mello,

Thanks for reporting this.

The repository administrator is on leave until the end of August, so assigning triage/write permissions and formally following up on this will have to wait until then.

Apologies for the delay, and thanks for your patience.

[sarmento]

Obrigado @Aryele-Mello — mas neste momento não vamos conceder write/triage neste repositório. Deixa-me explicar o modelo para ficar consultável (já falámos ao vivo, mas vale a pena tê-lo escrito):

O modelo é read-only + issues abertas

Continua a usar exactamente o padrão que já dominas: leitura do código + abertura de issues com os achados. É esse o valor da audit sweep, e é assim que os findings têm chegado aos donos dos repositórios com o rigor certo — o teu epic + individual findings na fccn/ai2-review-llms, fccn/ani-een, fccn/prr-tools, fccn/agent-team-cloud-eng, fccn/sifide-client e fccn/ai2-llm-text-classification são exemplo disso. Não precisas de write/triage para nada disso — e o fluxo do próximo passo (correcções, labels, triage) fica com os donos de cada repositório.

Porquê a separação

Duas razões concretas:

1. A verificação é mais forte quando o auditor e o fixer são pessoas diferentes. É o mesmo princípio que aplicamos ao review-before-merge nos PRs: o próximo par de olhos é sempre outro. Se o auditor também triaged/patched, perdemos essa separação sem ganhar velocidade.
2. O scope do write/triage é muito mais alargado do que os findings — inclui close/label/assign de tudo o resto no repo, e isso é uma responsabilidade que fica com quem opera o repo diariamente.

O que continua a acontecer

• Novos findings — continua a filar-os, ficas totalmente coberta pelo acesso read. Chegou muito boa qualidade nas últimas 48h; mantém.
• Triagem + correcções — os donos de cada repo respondem. Onde há bloqueios, pinga-nos.
• Acesso a read em repositórios adicionais — se ao longo da sweep faltar acesso a algum, abre um pedido específico (não um write/triage, apenas read) e resolvemos.

Fecho esta issue como not_planned — a not planned é literalmente sobre o scope pedido, não sobre a sweep. A sweep continua bem-vinda.

[sarmento]

Thanks for surfacing the findings, @Aryele-Mello — the audit shape you're running (Amara/Viktor/Rex/Idris/Priya, read-only + static analysis) is doing exactly what it should on this repo.

On the access ask specifically: keeping you at read + file-issues on this one, not triage/write. The reason is posture, not signal-quality: across the ecosystem-wide security-squad sweep, the auditor role and the implementer role deliberately stay distinct. The audit surfaces findings; the repo's own contributors take them from finding → fix → PR. Widening the auditor's write surface at ecosystem-scale would collapse that separation and make the audit less useful as an external lens.

What that looks like operationally:

1. File the findings as issues here — you already have that capability. Rich diagnosis + reproduction + proposed fix (in the shape of fccn/agent-core#86, which was decisive) is exactly the input the repo owners need to act quickly.
2. The repo's own contributors take them forward — CODEOWNERS + team-review flow handles the implementation. If a finding lands and nobody picks it up in reasonable time, ping me here on the issue and I'll route it.
3. If a specific finding needs write access (e.g. running a repo-local tool to gather more evidence, or you want to open a PR because the fix is trivial), name the specific case here and we handle it per-issue rather than as a blanket grant.

One per-repo exception exists: fccn/ani-een has write for you as of 2026-08-21 because it's a team system repo, not an ecosystem-audit target — same collaboration shape as the rest of that team. That's a decision about that repo's role, not a change to the audit-sweep posture on this one.

Closing this access-request issue with that framing. The audit findings themselves — separately filed on the Security Epic linked to this sweep — stay open and get the same triage priority they'd get from any team member. Please continue.