Is the security reporting / Bug Bounty channel referenced in SECURITY.md actively monitored?

[antosec00]

Hi Arc / Circle maintainers,

I have a process question about the private security-reporting channel referenced in this repository's SECURITY.md.

I am not reporting or discussing any vulnerability details in this public thread.

SECURITY.md directs security researchers to report vulnerabilities privately through Circle's Bug Bounty Program. Could a maintainer please confirm whether that reporting queue is currently actively monitored and routed to the appropriate Circle security owners?

For researchers using the documented private channel, it would be helpful to clarify:

1. Is the Bug Bounty / security-reporting queue referenced in SECURITY.md currently active and monitored?
2. What acknowledgement timeframe should a researcher normally expect after submitting a security report?
3. If a privately submitted report remains without a substantive response for several weeks or months, what is the appropriate escalation path?
4. Is Circle's [Bug Bounty Program] currently the only supported private reporting route for this repository, or is there another private channel that researchers should use for follow-up or escalation?

Again, I am intentionally not including any report IDs, vulnerability descriptions, affected components, reproduction details, severity information, or other security-sensitive material here.

The purpose of this discussion is only to confirm that the private reporting route documented by the repository is functioning and that long-pending private security reports have a defined escalation path.

Thank you.

[osr21]

Not a maintainer, so I can't speak to whether anyone at Circle is watching the queue internally — but most of this is answerable from published data, and I checked it rather than guessing. All values below verified 2026-09-02.

There's also one thing nobody has flagged that I think is the actual answer to your question.

1. Is the program active?

The program circle-bbp referenced in SECURITY.md is live and accepting reports right now:

Signal	Value
submission_state	open
rejecting_submissions	false
Publicly launched	2024-05-28
Participating researchers	160
Resolved reports	35
HackerOne response-efficiency indicator	ok

So it isn't a dead or paused program — reports are being received and resolved, and HackerOne's own responsiveness indicator (computed from recent first-response times) is not flagging it.

2. Acknowledgement timeframe

The program policy publishes an explicit SLA table, which is the authoritative answer here:

Type of Response	SLA in business days
Time to first response (from report submit)	5 days
Time to triage (from report submit)	10 days
Time to bounty (from triage)	10 days
Time to Resolution	depends on severity and complexity

Worth noting the policy frames these as targets Circle "will endeavour to meet", not guarantees.

3. The scope gap — probably the real issue

This is the part I'd want a maintainer to answer. I read the full program policy (~8.2 KB), and arc-node is not an enumerated asset in it. The in-scope surface is Circle's hosted product: the sandbox environments, the Circle APIs, developers.circle.com, and the USDC/stablecoin documentation. The Program Rules say plainly:

Testing should be done on app-sandbox.circle.com and api-sandbox.circle.com.

There is no mention anywhere in the policy of arc-node, the Arc chain, node software, GitHub repositories, or open-source components. The out-of-scope list is likewise oriented around web-application findings.

That matters for your question: SECURITY.md routes vulnerabilities in this repository to a program whose documented scope is Circle's hosted API and web surface. A report about node software can therefore be sitting in a queue that is being monitored and is meeting its SLA for in-scope reports, while a node report has no obvious owner in it. That would produce exactly the silence you're describing, without anyone ignoring anything.

4. There is a second private route, and it's already enabled

SECURITY.md presents the bounty program as the only channel, but GitHub private vulnerability reporting is enabled on circlefin/arc-node — I confirmed via the API (enabled: true; also on stablecoin-evm, evm-cctp-contracts, and noble-cctp). That means https://github.com/circlefin/arc-node/security/advisories/new works today.

Practically this is a different audience: a private draft advisory notifies the repo's admins — the people who actually maintain arc-node — rather than the bounty triage layer. For a node-software report specifically, that's the channel most likely to reach someone who can act on it.

The caveat is that it's enabled but undocumented, so it carries no stated SLA or safe-harbour coverage. That's a gap maintainers should close in one direction or the other.

5. Escalation

The program has allows_disclosure_assistance: true, so HackerOne's mediation and disclosure-assistance process is available for a report that has stalled past the stated targets — that's the supported escalation route, and it operates within the program rather than around it.

I'd specifically avoid self-disclosing while waiting. The Terms and Conditions state that by submitting, you agree not to publicly disclose findings or submission contents to any third party without Circle's prior written consent — so mediation is the safe path, not a public writeup.

Suggestions for maintainers

The SECURITY.md here is 330 bytes and was added in the initial open-sourcing commit (3e2f9f4, 2026-04-02); it has not been modified since. The same boilerplate appears near-verbatim in stablecoin-evm, evm-cctp-contracts, and noble-cctp — and the noble-cctp copy points at hackerone.com/circle, which 404s, which suggests the template isn't being reviewed. There's also no RFC 9116 security.txt on circle.com, www.circle.com, or developers.circle.com (all 404), so there's no out-of-band contact discoverable by the standard mechanism either.

Three concrete fixes:

1. Document the GitHub private reporting route in SECURITY.md. It's already enabled; a researcher has no way to know that from the policy.
2. Clarify whether arc-node is in bounty scope. Either add the node/chain assets to the program's scope, or state in SECURITY.md that open-source repository issues route via GitHub advisories instead. Right now the policy points somewhere that doesn't list this repo.
3. Fix the dead hackerone.com/circle link in noble-cctp.

Happy to open a PR against SECURITY.md for items 1 and 3 if maintainers want it.