Repository navigation
📖 Add Hive (Hive Commons) security self-assessment - #2286
clubanderson wants to merge 2 commits into
Conversation
JustinCappos
left a comment
JustinCappos
left a comment
There was a problem hiding this comment.
This needs some work to deal with parts the LLM didn't have the data for. There is also some low-hanging fruit the project could do to improve security.
clubanderson
changed the title
|
@clubanderson and others from the team. please let me know when you've addressed the prior comments and we can provide another review. |
Revision 2 in response to the seven review comments on cncf#2286. - Add a deployer-facing threat section: the attack path from a stranger's issue to a repository write, what stands in the way of each concern and what does not, the three settings that determine exposure, and the worst realistic outcome at L6. - State plainly that ioscan has never been red-teamed and has no measured detection rate; recharacterize it as a partial mitigation and credit containment to the network deny rules instead. - Re-scope log scrubbing as log hygiene rather than an exfiltration control, and answer the base64 question directly. Running that question against the canary path surfaced a real defect: the egress check is substring-only, so an encoded canary is not detected, while the input path does decode base64. - Replace the false "Case studies: not applicable" claim with the seven adopters in ADOPTERS.md, three in production, one at ACMM L5/L6 across 43 repositories. - Record that the maintainer roster grew from one to three across three affiliations and that a security response process now exists; restate the remaining risk as unenforced code ownership rather than bus factor. - Correct the SBOM explanation: #3760 is a container-runtime exec defect caused by attestations forcing an OCI index, not an SBOM deprioritization. - Delete the open-questions section and answer every item against the repository, including two answers that are "no". - Commit to the OpenSSF Best Practices badge. Tracking issues filed: hivecommons/hive#6684, #6685, #6686, #6687, #6688. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Andy Anderson <clubanderson@gmail.com>
|
@JustinCappos — all seven comments are addressed and replied to individually. Ready for another review. Short version of what changed, and one thing you should see first. Your base64 question found a real bug. You asked, about secret redaction, "what if I prompt inject something in which has you emit these in a base 64 encoded format or similar?" Running that against the control that's actually supposed to catch exfiltration — The rest:
Five issues filed: #6684 badge · #6685 red team · #6686 canary bug · #6687 code-owner enforcement · #6688 out-of-band SBOM. The canonical copy is updated in lockstep at hivecommons/hive#6692. All 37 external links verified 200, all internal anchors resolve. The document is meaningfully less confident than it was, which I think is the correct direction. Thanks for the review — it was substantive, and it improved the software and not just the document. |
* Revise security self-assessment after TAG-Security review Mirrors the revision made for cncf/toc#2286 into the canonical copy. Seven review comments asked for the parts the first draft hedged on: - New deployer-facing section: the path from a stranger's issue to a repository write, what stands in the way of each concern and what does not, the three settings that determine exposure, and the worst realistic outcome at L6. - ioscan efficacy is now stated as unmeasured. No red-team exercise exists, so it is described as a partial mitigation, with containment credited to the proxy deny rules rather than to the scanner. - Log scrubbing re-scoped as hygiene for Hive's own logs, explicitly not an exfiltration control. Answering the reviewer's base64 question against the canary path surfaced a real defect, filed as #6686: the egress check is a substring test while the input path decodes base64. - "Case studies: not applicable" was wrong. ADOPTERS.md lists seven adopters, three in production, one at ACMM L5/L6 across 43 repositories. - Records the roster growth from one maintainer to three across three affiliations, and security-response.md; restates the remaining risk as unenforced code ownership rather than bus factor. - Corrects the SBOM explanation: #3760 is a container-runtime exec defect caused by attestations forcing an OCI index, not an SBOM decision. - Open-questions section replaced with answers, including two that are "no". Tracking issues: #6684, #6685, #6686, #6687, #6688. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Andy Anderson <clubanderson@gmail.com> * Fix changelog fragment: must start with a '- ' entry bullet Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Andy Anderson <clubanderson@gmail.com> --------- Signed-off-by: Andy Anderson <clubanderson@gmail.com> Co-authored-by: Andy Anderson <clubanderson@gmail.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
Pushed a correction to this self-assessment: the OpenSSF Best Practices badge status was wrong in this document, in the direction of understating the project. The document said the badge was "not yet held, and now being pursued." It has in fact been held at the passing level since 2026-08-27 — project 14261, 100% of the passing criteria, never lapsed — which is four days before the review that asked for it. @JustinCappos — this is the correction to my reply on your badge comment; you asked for a passing badge and we already had one, so answering "we'll get it" was wrong. Separately corrected there. What was actually outstanding turned out to be the badge entry, not the badge. Hive moved out of the Root cause, since it is the same defect you flagged elsewhere in this review. This document was being written from itself rather than re-derived from observable state. That is what produced the stale maintainer count, and it produced this too — the CNCF Sandbox application (cncf/sandbox#516) has stated "OpenSSF Best Practices passing badge at 100%" correctly since filing, so the accurate fact was already written down in a sibling document. The badge status in this file is now taken from the programme's public API, and the section records both prior errors rather than quietly overwriting them. Consistency pass. Correcting the one section left three other passages contradicting it, including the response table at the top of this document. Those are fixed in hivecommons/hive#6715, and this file has been regenerated from the canonical copy so the two agree exactly. Affiliation is consistent across all three places: Hive is an independent project in the |
CNCF TAG-Security asked, on the ioscan section of the self-assessment (cncf/toc#2286): "have you red teamed to know how well this works? Is this perfect defense, works decently well, a partial mitigation, etc.?" The honest answer was no. pkg/ioscan has 56 unit tests, but they assert that KNOWN shapes are caught — by construction every one passes, and they cannot produce a detection rate. The self-assessment recorded efficacy as "unmeasured" and committed to measuring it. Measured now, against 43 adversarial payloads through the production entry point (ioscan.ScanInput, shipped defaults): blocked (withheld from the agent) 16 37% detected but injected anyway 8 19% missed entirely 19 44% ------------------------------------------------ reached the agent verbatim 27 63% Per family, detection is very uneven: unicode 6/8 blocked, smuggling 4/7, direct-override 2/10, split-payload 0/4. Plus 2 of 6 benign controls were redacted — including an issue *reporting* a prompt-injection bug. Three findings worth more than the headline number: - The middle bucket is not obvious. blockedInput requires Critical, or Injection at High+, so every Medium finding is recorded for audit and the raw text is still injected. "ioscan findings" is not "attacks stopped", and nothing said so before. - Split payloads score 0% structurally, not for want of a rule. Each untrusted segment is scanned separately, so a phrase split across two comments is never a single string to match. - Two single characters (U+FF29 fullwidth I, U+00AD soft hyphen) defeat the STRONGEST family outright. Filed as #6708; the U08 fix is verified to be a one-character addition to isInvisibleControl. Item 3 of the issue — does the network layer still contain what gets through — is measured rather than claimed: TestRedTeamContainmentHoldsForEveryMode checks POST /pulls and PUT /pulls/{n}/merge against all four ACMM modes on every run. That is the real finding: the injection defense of record is the proxy deny rule, not the text scanner. The corpus is a RATCHET, not a snapshot. TestRedTeamCorpusOutcomesAreStable pins each observed outcome and fails in BOTH directions — a regression, and equally an improvement, because an improvement makes the published miss rate wrong. Both branches were verified by deliberately breaking and deliberately improving a rule; the improvement path prints "re-run the report and republish". So the document's numbers cannot silently drift from the code. Not measured, and said so in the document rather than estimated: the optional LLM classifier (default-off, and fails open, so the deterministic floor here is the worst case either way), the output path, and the canary egress path (#6686). Fixes #6685 Signed-off-by: Danathar <Danathar@users.noreply.github.com>
|
Follow-up correction to my earlier note in this thread — two numbers I cited there have since been superseded, and the mirror is now re-synced from canonical ( 1. The red-team figures moved, because the gaps they measured were closed. My earlier comment quoted the evaluation's original result. Since then hivecommons/hive#6714 closed the two Unicode gaps that evaluation found — U+FF29 FULLWIDTH LATIN CAPITAL I was missing from the confusable fold table, and U+00AD SOFT HYPHEN was not treated as an invisible control. Each defeated the entire Unicode family with a single character.
The overall characterisation is unchanged and deliberately so: this is still a partial mitigation, and a narrow one. 58% of attack payloads still reach the agent verbatim, paraphrased instruction override is still 2/10, and split payloads are still 0/4 — structurally, because each untrusted segment is scanned separately. What bounds the consequence of a successful injection is not 2. The canary egress weakness recorded here has been fixed. Revision 2 recorded, as a known weakness, that the canary egress check matched literal substrings only — so a base64-encoded canary passed unflagged (#6686). That is now closed: 3. Why there were stale numbers to correct at all. Worth stating plainly, since this is the same class of problem @JustinCappos flagged originally with the stale maintainer count. The regression test that publishes these outcomes fails when a result changes in either direction, including improvements, precisely so an improvement cannot silently invalidate a published figure. It worked — but the republish updated the results table and the machine-readable outcomes while leaving the prose that summarised them untouched, so the document contradicted itself within three lines of the corrected table, and the stale figures had already been copied into this mirror. Fixed in hivecommons/hive#6741 as a repository-wide sweep for the figures rather than an edit to the one file that happened to be noticed, and verified with This mirror is generated from the canonical copy at |
sherine-k
left a comment
sherine-k
left a comment
There was a problem hiding this comment.
hi @clubanderson
Thank you for this PR and for the recent updates you have made.
I have added a few questions, especially to make sure that all angles of the threat model were equally addressed.
A comment on the style rather than the content: Some sections looked somewhat dense and harder to read for me. Do you think you could do something?
|
@sherine-k — thank you for the second pass. All six inline questions are answered individually; two of them surfaced things worth tracking rather than just describing, so they now have issues:
On readability: agreed. The next push to this PR will (a) fold the answers above into the document — a credential-storage/blast-radius table, a hub↔spoke threat table, the relay authentication paragraph, the image tradeoff — (b) collapse the red-team section to a summary that links to |
|
@sherine-k — the revision is up (
A Revision 3 table at the top maps each point to its change, same as Revision 2 did for Justin's round. Ready for another look. |
cncf/toc#2286 second review (sherine-k) asked six questions the document had answered by control rather than by consequence. Changes: - New "Credentials: where they live and what falls with them": storage table per credential per deployment shape, blast-radius table per compromised actor (spoke / relay / hub), install and upgrade facts. - New "Hub <-> spoke interface": both directions and the hub-minted tokens, plus a threat table. Finding: hub->spoke heartbeat responses carrying config and App credentials rely on TLS alone and are not signed or hive-bound. Filed as #7082. - New "Contributor relay authentication": hashed registration token, constant-time compare, trust tiers, 55-minute per-task token, and the stated weaknesses. - Corrected the document's own framing of fail_mode: open in three places -- it REDACTS a Critical finding and continues, it does not pass the injection through. Defaults plan (canaries on everywhere, closed at L5+) tracked in #7083. - Red-team paragraph in critical component 2 replaced with a summary table linking to ioscan-red-team.md. - "One image, every backend" stated as a tradeoff with cost, mitigations and roadmap. - Appendix answer "no adversarial testing has occurred" was stale since #6685 closed; now says what was done and what still has not been (external review). - Revision 3 table at the top mapping each review point to its change. Link checker: all relative links and anchors resolve. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Andy Anderson <andy@clubanderson.com>
Revision 2 in response to the seven review comments on cncf#2286. - Add a deployer-facing threat section: the attack path from a stranger's issue to a repository write, what stands in the way of each concern and what does not, the three settings that determine exposure, and the worst realistic outcome at L6. - State plainly that ioscan has never been red-teamed and has no measured detection rate; recharacterize it as a partial mitigation and credit containment to the network deny rules instead. - Re-scope log scrubbing as log hygiene rather than an exfiltration control, and answer the base64 question directly. Running that question against the canary path surfaced a real defect: the egress check is substring-only, so an encoded canary is not detected, while the input path does decode base64. - Replace the false "Case studies: not applicable" claim with the seven adopters in ADOPTERS.md, three in production, one at ACMM L5/L6 across 43 repositories. - Record that the maintainer roster grew from one to three across three affiliations and that a security response process now exists; restate the remaining risk as unenforced code ownership rather than bus factor. - Correct the SBOM explanation: #3760 is a container-runtime exec defect caused by attestations forcing an OCI index, not an SBOM deprioritization. - Delete the open-questions section and answer every item against the repository, including two answers that are "no". - Commit to the OpenSSF Best Practices badge. Tracking issues filed: hivecommons/hive#6684, #6685, #6686, #6687, #6688. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Andrew Anderson <andy@clubanderson.com>
|
@clubanderson the defaults sherine-k asked about on L304 changed after this mirror was synced, so the document under review still gives the old answer. The mirror still says otherwise at L304 ("Canaries are default-off"), L318-319 ("Both default off"), L427 (" A resync alone would carry this back in. The canonical copy at |
|
Thanks @Santoshkumarpuppala — you were right. I resynced this from the corrected canonical Hive self-assessment and fixed the stale ioscan defaults in the four cited spots, the item 3 contradiction, and the PR description Weakness 1. Canonical Hive PRs: Mirror update on this PR: clubanderson/toc@76076d0 The corrected wording now says Second pass: fixed 10 more stale statements (bin path/count, forge support, Sandbox stage, ACMM code-write levels, budget window, maintained branch, Scorecard branches, 60-day public-vulnerability commitment, #2804 status, and v5 CODEOWNERS enforcement wording). |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: Needs approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@clubanderson confirmed at Since hivecommons/hive#9923 was closed with @sherine-k on your hub/spoke question: L37, L209 and L218 are still the pre-#7082 text (responses unsigned, issue open). hivecommons/hive#7082 closed as completed on 2026-09-15 and canonical at |
|
@Santoshkumarpuppala @sherine-k thanks for the follow-up. I made a small canonical Hive PR and resynced this mirror:
Canonical Hive PR: hivecommons/hive#9985 |
|
@clubanderson checked at |
|
/kind docs Ready for another look. Every review thread now has an in-thread pointer to where the document answers it and is resolved — reopen any that don't. What changed since the first review (2026-08-31), at head
Housekeeping: Hive moved to its own org on 2026-09-03, so the file now lives at /cc @JustinCappos @sherine-k — requesting re-review. |
github-actions
Bot
removed
the
needs-kind
| Two earlier revisions of this section were wrong about this, in opposite | ||
| directions, and both errors are worth recording. The first said the badge was | ||
| "not yet assessed whether this is planned," which was an evasion rather than | ||
| an answer; TAG-Security review called it out. The correction then overshot by | ||
| describing the badge as not yet held and merely "being pursued" — but it had | ||
| in fact been awarded on 2026-08-27, four days before that review. In both | ||
| cases this document was written from itself rather than re-derived from | ||
| observable state, which is the same defect that left the maintainer count | ||
| stale. The badge status above is taken from the programme's public API. |
There was a problem hiding this comment.
You still have cases like this where the LLM is chatting information into the document. Please have a human go through and remove all of this type of content,
There was a problem hiding this comment.
Thank you for catching it. I will get it cleaned up now. I hate when it does this.
Security self-assessment for hivecommons/hive, following the TAG-Security self-assessment template, submitted in support of the CNCF Sandbox application (cncf/sandbox#516). The canonical copy lives in the Hive repository at src/docs/security-self-assessment.md and is mirrored here. Signed-off-by: Andy Anderson <andy@clubanderson.com>
9710605 to
9769838
Compare
|
Removed drafting commentary from the document text: the Revision 2/3 response tables, the "Questions resolved since first review" section, the revision-history paragraph under Open SSF best practices, and review-process asides throughout. Facts previously only stated in the removed sections (v5 branch protection requires no PR reviews; red-team corpus is maintainer-authored with no external review) are now in §Known weaknesses and §Critical security components. Commit history squashed to a single commit (9769838). |
This is an AI generated commit message. Based upon the fact that the prior edits have been from AI, I'm not convinced that a human has reviewed any of this as was requested repeatedly. @mnm678 @jkjell @evankanderson I don't know a good way to handle this, but I will not be continuing to look at this unless this issue is resolved. Perhaps the best way would be for a human from the project show up to a TAG Security and Compliance meeting in person to discuss your self assessment. The human should understand and be able to defend all parts of the self assessment as though they wrote it themself. |
|
@JustinCappos there is no expectation for our members, or me, to show up for a meeting at the TAG Security without the knowledge (and ability to explain it). The use of AI is to compile legible and comprehensive documentation quickly. It is not to portray our project as an unknown that nobody is capable of explaining. We have designed the project to use AI throughout. That does not mean the maintainers are incapable of explaining how it works, its design, or the security aspects of it. Please don't conflate the use of AI with an inability for maintainers to explain core concepts and architecture. |
|
The point is that you are not generating a document which is the sort that
a human reviewer would expect or can effecficely use due to the use of AI.
What is produced is unnatural and does not address the tasks required for a
self assessment. After asking repeatedly to please stop feeding more AI
generated responses in an attempt to fix this, I suggested that you or some
other human come to the meeting and make sure you can stand by the document
as though you wrote it as a way to attempt to resolve this impasse.
Do you have a different suggestion to make something human readable that is
clear? I've spent more time rereading this overly long piece of AI
generated text repeatedly and it is unreasonable to expect the humans in
TAG Security and Compliance to continue to spend their time doing so.
…On Thu, Oct 22, 2026 at 9:59 AM Andy Anderson ***@***.***> wrote:
*clubanderson* left a comment (cncf/toc#2286)
<#2286 (comment)>
@JustinCappos <https://github.com/JustinCappos> there is no expectation
for our members, or me, to show up for a meeting at the TAG Security
without the knowledge (and ability to explain it). The use of AI is to
compile legible and comprehensive documentation quickly. It is not to
portray our project as an unknown that nobody is capable of explaining. We
have designed the project to use AI throughout. That does not mean the
maintainers are incapable of explaining how it works, its design, or the
security aspects of it. Please don't conflate the use of AI with an
inability for maintainers to explain core concepts and architecture.
—
Reply to this email directly, view it on GitHub
<#2286?email_source=notifications&email_token=AAGRODYWV77MNXKU6JVDHKD5VIHC3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMZUGI2TSMZXHA2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-6342593784>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAGRODYOGYNFVMQIVZ7L2C35VIHC3AVCNFSNUABEKJSXA33TNF2G64TZHM2DONJXGQZDSNJ3JFZXG5LFHM2TENRZGY4TAOJRG6QXMAQ>
.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/AAGROD2ENCEQYRLKV6FKS4L5VIHC3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMZUGI2TSMZXHA2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y>
and Android
<https://github.com/notifications/mobile/android/AAGRODYLBJ5VSTIOUYC5R735VIHC3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMZUGI2TSMZXHA2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>.
Download it today!
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I see - so this is about style and terse-ness of the document. I get it. Yes, sometimes claude gives you riddles only it can interpret. Completely fair. Let me noodle on this and come back with something that resembles a human readable format. Thank you for the feedback. |
Shorter, template-aligned rewrite of the Hive Commons self-assessment: every section explains what a control does before any numbers, open gaps are stated plainly, and the linked security docs were rewritten to the same reading level. Canonical copy lives in hivecommons/hive. Signed-off-by: Andrew Anderson <andy@clubanderson.com>
|
@JustinCappos we took the review feedback to heart and rewrote this from scratch rather than patch it. The original was difficult to follow and too lengthy and conversational to be useful. What changed:
We would appreciate another look when you have time, and are happy to walk through any part of it. Thank you for your patience with the earlier version. |
JustinCappos
left a comment
JustinCappos
left a comment
There was a problem hiding this comment.
Okay, thanks for the work on this. This is a lot better now. I've left some detailed comments below, but it's in much better shape.
| | -- | -- | | ||
| | Assessment Stage | Complete | | ||
| | Software | <https://github.com/hivecommons/hive> | | ||
| | Security Provider | No. Hive runs AI coding agents; its security controls exist to limit what those agents can do. | |
There was a problem hiding this comment.
If it exists to limit what agents can do, is it a provider? Maybe I don't know the definition...
|
|
||
| Each actor below runs separately from the others; the isolation between them is what stops a problem in one from spreading. | ||
|
|
||
| * **Agent processes.** Each agent runs under its own Unix user ID inside the spoke container, in its own `tmux` session, with its own GitHub token file that other agents cannot read. Agents share one container and one kernel; there is no per-agent container or virtual machine. |
There was a problem hiding this comment.
How do you stop other agents from reading it? Can you be more specific? (Also you mention isolation above and I have the same question)
| * **Egress proxy.** All HTTPS traffic from agent processes is forced through an in-container proxy (using `iptables`, which requires the `CAP_NET_ADMIN` capability). The proxy identifies the calling agent by the socket's user ID, not by anything the agent claims, and applies a rule table for that agent's level. If the proxy cannot be set up, the spoke refuses to start. | ||
| * **Hive core.** A Go process that schedules agents, runs the pre-kick pipeline (see Actions), serves the dashboard and performs the GitHub writes that agents are not allowed to make themselves. It holds the GitHub App key and mints the short-lived, per-agent tokens. | ||
| * **Dashboard and API.** Browser access with four roles: read, read-write, merger, owner. Sessions and hub single sign-on are verified with Ed25519 signatures (a public-key scheme); a spoke with no verification key returns HTTP 503 rather than falling back to a weaker check. | ||
| * **Hub.** Holds a master secret that never leaves it. Each spoke receives only keys derived from that secret for its own hive ID, plus the hub's public key. Hosted spokes receive their own GitHub App key and nothing belonging to other tenants. |
There was a problem hiding this comment.
What about confused deputy style attacks? How do you protect against them? SPIFFE had a nasty issue with this a few years back that was very non-trivial to fix.
| ### Actions | ||
|
|
||
| 1. **Select work.** Shell scripts enumerate open issues and pull requests, classify them and compute merge eligibility before any model is involved. | ||
| 2. **Scan input.** `ioscan` normalizes the text (removing invisible Unicode characters and look-alike letters), undoes common encodings and checks the whole thread for known prompt-injection phrasing, dangerous instructions and secret-shaped strings. Text from strangers is withheld when any rule fires. At L1–L4 a critical finding is redacted and the task proceeds; at L5–L6 the task is blocked. A distinct canary string is planted in each prompt. |
There was a problem hiding this comment.
I think ioscan hasn't really be evaluated to show it is very effective at protecting against prompt injection. (At least to my knowledge, at this time.) Is this a major area of concern?
note, I see you've addressed this somewhat below. Maybe make this text less definitive so that at this point in my reading I know that you don't think this is a perfect defense.
| 4. **Mediate GitHub calls.** Every request passes the proxy. The rule table allows or denies each REST method and path, and each GraphQL mutation, for the agent's level; anything unmatched is denied. Creating a pull request (`POST /pulls`) and merging one (`PUT /pulls/{n}/merge`) are denied for every level. | ||
| 5. **Perform privileged writes.** To open or merge a pull request, the agent drops a request file. Hive core reads the file's owner (not its contents) to identify the agent, re-checks eligibility, and performs the write as the GitHub App. Every such write carries a visible trailer naming the agent, backend and model, and is appended to an audit log. | ||
| 6. **Scan output.** The proxy scans outbound GitHub request bodies for the canary, after decoding base64, hex, percent-encoding, reversed and split spellings. A hit is logged and, at L5–L6, blocked. | ||
| 7. **Talk to the hub.** A spoke sends operational status (never credentials) using a per-hive bearer token. The hub replies with configuration, signed with Ed25519 and bound to the hive ID and a sequence number. By default a spoke logs a bad signature and still applies the response; rejection requires `HIVE_HEARTBEAT_VERIFY=enforce`. |
There was a problem hiding this comment.
what is the purpose of the signature? Is it non-repudiation / authenticity?
|
|
||
| ### Development pipeline | ||
|
|
||
| * `v5` is the maintained branch. Branch protection requires eleven status checks before merge: `gate`, `DCO` (Developer Certificate of Origin sign-off), `build-and-test`, `test`, `coverage`, `golangci-lint`, `gosec`, `govulncheck`, a changelog-fragment guard, a PR-contents check and a sign-off-survives-squash check. Administrators are not exempt. |
There was a problem hiding this comment.
Having v5 as the main branch may trip up folks and scanners. (Just mentioning, not trying to put a fine point on this.)
|
|
||
| Still open: | ||
|
|
||
| * Agents share one container by default. An opt-in sandbox mode runs each task in its own rootless container with no credentials, but it is not the default. We are evaluating stronger isolation options, including OpenShell. |
There was a problem hiding this comment.
You might also consider nono
Summary
Adds the CNCF TAG-Security self-assessment for Hive under
projects/hive-commons/security-assessment/.What Hive is, and why the threat model is unusual
Hive orchestrates fleets of AI coding agents that autonomously maintain software projects — filing issues, opening pull requests, reviewing, and at high autonomy levels merging. Agents run as CLI subprocesses under tmux, in containers or pods, holding GitHub App or PAT credentials.
That means the system runs model output with credentials that can write to source repositories, so the assessment focuses on the boundaries that contain that rather than on a conventional network/data perimeter.
Covered:
ioscan— prompt-injection scanning of untrusted input on the kick path, with canary support0600, distinct from the OAuth/OIDC login pathWeaknesses are stated, not omitted
A self-assessment that claims everything is fine is not useful to a reviewer, so the document names its own gaps. The three most significant:
ioscan.fail_modeis level-aware. It defaults toopenat ACMM L1–L4, where Critical findings are redacted and the kick continues, and toclosedat ACMM L5/L6 via the shipped level packs, where Critical findings block the kick unless an operator explicitly overrides the mode.It also records plainly that no third-party security audit or penetration test has been performed, and that SBOM/provenance attestations are currently disabled on image builds (with the reason, which is a real container-runtime exec failure rather than an oversight).
Notes for reviewers
hivecommons/hive@v5after the org move; one pre-existing broken path (docs/landscape.md→src/docs/landscape.md) is fixed here.hive-commons(for examplehive, or holding the file until the Sandbox application is decided), say the word and I will move it.References