Add security-model discoverability pointer to the project-wide CloudStack threat model#149
Add security-model discoverability pointer to the project-wide CloudStack threat model#149potiuk wants to merge 2 commits into
Conversation
Adds a draft project-level security threat-model document (draft-THREAT-MODEL.md) at repo root, improving discoverability for automated security scanners running against this repository. The file follows the rubric format used by several other ASF projects piloting security-model discoverability. The "draft-" prefix signals this is a proposal for the PMC to review, correct, or reject — not a finalised maintainer-blessed model. Every claim carries a provenance tag (documented / inferred / maintainer) so reviewers can see where each claim originates; §14 collects open questions for the maintainers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
0f8d4ea to
b6579f6
Compare
|
There's a lot of details in the draft that needs a better set of eyes, so assigning @DaanHoogland @vishesh92 who're also PMC leads on the work. |
|
Thanks @yadvr, I think we should start with this one and work from there. I’ll look at the fields we need today cc @vishesh92 @potiuk |
| **Q1.** Out-of-scope: where the caller stores `apiKey` / `secretKey` | ||
| on disk. Confirm. |
| **Q2.** Out-of-scope: revalidating management-server response | ||
| correctness in the SDK. Confirm. |
There was a problem hiding this comment.
this is a cloudstack issue only to the extend of the SDK used is delivered by the Apache CloudStack project, and assuming the reponse was given by a cloudstack installation of the targeted version. Any misdirection, mismatched version, or spoofed server is out of scope.
| **Q3.** `HTTPGETOnly` default and signature-in-URL leakage — is `false` | ||
| the default and is "do not log URLs when `HTTPGETOnly = true`" a | ||
| documented caller responsibility? *(maps to §5a, §6, §10, §11a)* |
There was a problem hiding this comment.
confirmed (I.E. +1 for my part)
Given that this “inherits” from cloudstack, i think (on second thought) we should start there. |
|
Agreed @DaanHoogland — let's converge on the parent |
…po copy Drop the standalone draft-THREAT-MODEL.md and wire the discoverability chain AGENTS.md -> SECURITY.md -> the project-wide model in apache/cloudstack (apache/cloudstack#13293), so scanners find one canonical model and this repo inherits it rather than duplicating it. Generated-by: Claude Code
|
Note on the failing Apache RAT Check — it's the workflow's RAT-download step, not this PR. The job fetches |
Summary
Apache CloudStack's security model is project-wide, not per-repository. This PR replaces the earlier standalone
draft-THREAT-MODEL.mdin this repo with the standard discoverability chain so automated scanners find the one canonical model:AGENTS.md→SECURITY.md→ the project-wide model athttps://github.com/apache/cloudstack/blob/main/THREAT_MODEL.mdThe model lives in
apache/cloudstack(see apache/cloudstack#13293); this repo inherits it via the pointer above rather than duplicating it — per the PMC's direction on #13293 to converge on the parent model first. The link resolves once that model lands onmain. A thin repo-specific addendum can be added here later if this component needs one.AGENTS.mdcarries a one-line SPDX header (it is read by agents on every session);SECURITY.mdcarries the full ASF header.