Vulnerability Disclosure Policy

1.1 Assets:

1.2 Finding types we especially want:

• authentication or session flaws, including MFA bypass
• tenant isolation failures: any path that reads or writes another tenant's data
• privilege escalation within a workspace, or from user to administrator
• anything that causes GitAegis to run a mutating Git operation without a capsule, or to report a capsule as taken when it was not
• anything that lets an operation bypass the Operation Preview or the refusal path
• capsule confidentiality or integrity flaws: a way to read plaintext from an uploaded capsule, to substitute a capsule, or to weaken on-device encryption
• update integrity flaws: installing an update that fails signature verification, downgrade attacks, or rollback abuse
• injection into Git subprocess arguments or environment, or escape from the pinned environment
• Safe Mode bypass, including anything that causes hooks to run while the hooks path is pinned away
• secret leakage: credentials, tokens, or keychain material exposed in logs, telemetry, error reports, or support bundles
• support bundle redaction failures, including the secret scanner missing a class of secret
• server-side request forgery, remote code execution, deserialisation flaws, path traversal
• stored or reflected XSS in the application, CSRF where it has real effect
• IDOR in the API
• local privilege escalation from the desktop application to the operating system

1.3 Findings against your own account and your own local installation are always in scope to test.

2.1 Assets that are not ours:

• GitHub, and any other provider you connect: report to them;
• any subprocessor listed at Subprocessors. Report to them, and tell us so we can follow up. None is engaged today;
• Git itself: GitAegis requires Git 2.38.0 or newer, already installed, and never bundles it. Report Git vulnerabilities to the Git project;
• another customer’s repositories, hosts, or infrastructure.

2.2 Activities that are out of scope regardless of the finding:

• denial of service, volumetric load testing, or resource exhaustion against production
• social engineering of our staff, our customers, or our vendors, including phishing and pretexting
• physical attacks against our staff or offices
• attacks on end-user devices you do not own
• automated scanning that generates significant load
• accessing, modifying, or exfiltrating data belonging to another customer: prove the vulnerability, then stop

3.1 The following are not usually accepted unless you can demonstrate a concrete, exploitable impact:

• missing security headers with no demonstrated exploit
• missing SPF, DKIM, or DMARC records on domains that do not send mail
• output from an automated scanner with no manual validation
• self-XSS requiring the victim to paste code into a console
• clickjacking on pages without a state-changing action
• CSRF on unauthenticated forms or on logout
• rate limiting on non-sensitive endpoints
• descriptive error messages that reveal no secret
• software version disclosure without a matching exploitable vulnerability
• weak TLS ciphers still enabled for compatibility with a supported client
• vulnerabilities requiring a rooted, jailbroken, or already fully compromised host
• vulnerabilities requiring physical access to an unlocked machine
• issues affecting a release older than the one before the current one
• best-practice suggestions with no security impact

3.2 A documented limit is not a vulnerability. The recoverability boundary is stated on the Recovery capsules page, in Terms §11, and in EULA §10: if a capsule was taken, you can roll the operation back; if a Flight Recorder event captured a state hash, you can roll back to that state; if any reflog entry, ref, branch, stash, or capsule references a commit, Lost Work can recover it. Outside those, it cannot. The documented non-restoration of rebase state, non-restoration of config, and the absence of a generic resume for bisect and a conflicted stash apply are behaviour, not vulnerabilities.

3.3 The exception, and it is important: if you can make the product’s stated behaviour false: a capsule reported as taken that was not, an operation that runs when the capsule failed and should have blocked it, a rollback that silently restores partial state, or a Lost Work scan that misses a commit still referenced by a source it claims to scan, that is in scope and we want it.

4.1 If you make a good-faith effort to comply with this policy during your research, we will consider your research authorised, we will work with you to understand and fix the issue quickly, and:

• we will not bring or support a civil claim against you in connection with it;
• we will not report you to law enforcement or support a criminal complaint in connection with it;
• we will not claim that your activity breached the Acceptable Use Policy, the Terms of Service, or the EULA, and we waive any anti-circumvention or reverse-engineering restriction in those documents to the extent needed for good-faith research within this policy;
• if a third party brings a claim against you for activity conducted in compliance with this policy, we will make it known that your activity was authorised.

4.2 This protection is for good-faith research only. It does not cover extortion, data theft, deliberate destruction, harm to other customers, or publishing before the timeline in section 9.

4.3 We cannot authorise testing against systems we do not control. Safe harbour extends only to our assets in section 1.1. Testing a subprocessor’s systems is a matter between you and them.

4.4 If you are unsure whether something is in scope or whether an action is permitted, ask first at security@gitaegis.com. Asking never counts against you, and we would rather answer a question than triage an incident.

4.5 We will not condition safe harbour on your signing a non-disclosure agreement, and we will not use a bug bounty payment as a mechanism to buy your silence.

4.6 This section has not yet been reviewed by counsel. Researchers rely on safe harbour language, and until a lawyer has approved it, treat the protections above as our stated intent rather than as settled contractual terms, and ask us under 4.4 if anything about that matters to you.

5.1 Use your own accounts and your own test data. If you need a second account to demonstrate a cross-tenant issue, create both.

5.2 Minimise impact. Stop as soon as you have proof. Do not pivot, do not persist, do not escalate beyond what the proof requires.

5.3 If you access another party’s data unintentionally, stop immediately, do not save it, tell us at once, and delete anything you obtained. Doing so promptly is treated as compliance with this policy, not a breach of it.

5.4 Do not degrade the service for other users.

5.5 Do not use a finding for anything other than demonstrating and reporting it.

5.6 Do not demand payment in exchange for withholding a report. That is extortion, and safe harbour does not apply to it.

5.7 Comply with applicable law. This policy cannot authorise anything the law forbids.

6.1 Email security@gitaegis.com.

6.2 PGP. No key is published for that address yet, so the machine-readable policy carries no Encryption field. If you have something you would rather not send in clear, say so in a first email with no detail in it and we will arrange a channel.

6.3 The machine-readable version of this policy is at /.well-known/security.txt, per RFC 9116.

6.4 We accept reports in English. Reports in other languages are welcome; expect translation delay.

6.5 You may report anonymously. We will still act on it, and we will still credit you if you later identify yourself.

6.6 Do not file a security report as a public issue, a public post, a support ticket, or a message to an individual employee. Use security@gitaegis.com so that it reaches the people who can act on it.

7.1 A useful report has:

1. A summary. One or two sentences of what the issue is and what it lets an attacker do.
2. The affected asset and version: URL, or the application version and platform from the About panel.
3. Reproduction steps: numbered, exact, from a clean state. Include requests, payloads, and account roles.
4. Impact: what an attacker gains, whose data, what actions, under what preconditions.
5. Preconditions: authentication required, privileges needed, user interaction needed, network position needed.
6. Evidence: screenshots, a short video, or request and response captures. Redact any third-party data.
7. Your assessment of severity, ideally with a CVSS v3.1 or v4.0 vector. We will do our own, and we will tell you if we disagree and why.
8. How you would like to be credited, or that you would prefer not to be.
9. Your disclosure intentions, including any deadline you are working to.

7.2 If your proof of concept touched data that is not yours, say so explicitly and tell us what you accessed. This is not held against you (section 5.3).

7.3 One issue per report. Chained issues can be reported together with the chain explained.

8.1 Every report goes through these stages:

• Acknowledgement, from a human rather than an autoresponder alone
• Triage and initial assessment: validity, severity, and whether we need more from you
• Status updates at a stated interval until the issue is closed
• Remediation or mitigation, prioritised by severity
• Confirmation to you when it is fixed, and a chance to verify it
• Public disclosure, coordinated with you under section 9

8.2 The clock attached to each stage is not set in this draft. A response-time commitment needs someone rostered to meet it, and publishing hours and days that nobody has agreed to staff would be worse than publishing none. A researcher will hold you to a number, and rightly. The windows are set before this policy takes effect.

8.3 We will tell you honestly if we are not going to fix something, and why. “Won’t fix” is an answer we are willing to give, with reasons, rather than leaving a report to go quiet.

8.4 Where a fix requires a desktop release, we will tell you the release plan and the version to look for. Where it requires a server change, we deploy it as soon as it is validated.

8.5 We publish security advisories for issues affecting released desktop versions on the Changelog, with the affected versions, the fixed version, the impact, and credit where you have accepted it.

8.6 Where an issue affected customer data, notification follows Privacy Policy §15 and, for business customers, DPA §11.

9.1 We ask you to give us time from acknowledgement before publishing, so that a fix can reach users. The length of that window is not set in this draft; until it is, we agree it with you at acknowledgement rather than assert one.

9.2 If the issue is being actively exploited, or a fix will take longer, we will talk to you about the timing rather than let the clock run out silently.

9.3 We will not ask for an extension more than once without giving you a concrete reason and a date.

9.4 We prefer to publish together: our advisory and your write-up on the same day, each linking to the other.

9.5 When you publish, please avoid including customer data, working exploit code for an unpatched issue, or details of another customer’s environment.

9.6 If we fail to respond as section 8 describes, you are free to disclose. We would rather be embarrassed by that than have you sit on an unfixed issue.

9.7 We request a CVE where the issue affects a released version of the desktop application, and we will credit you in the CVE record if you wish.

10.1 This draft does not answer that question, because the company has not decided. There are three honest answers (no paid programme, discretionary rewards, or a formal programme with a published table) and this policy states which one applies before it takes effect. Guessing on the company’s behalf would be worse than the delay: a researcher who reads “we pay” and then does not get paid is a worse outcome than one who reads a clear “no”.

10.2 Whatever that answer turns out to be, it does not change section 4. Safe harbour is not conditional on a payment being available, and it is not conditional on your accepting a reward.

10.3 We will not use a reward to buy silence, and we will not require a non-disclosure agreement as a condition of paying one.

11.1 There is no security acknowledgements page yet. Until there is, credit is given in the Changelog advisory and in the CVE record where one is requested.

11.2 You choose how you are credited: full name, handle, organisation, a link, or not at all.

11.3 Credit is given for the report, not for the outcome. A valid, well-documented report that turns out to duplicate an existing internal finding is still credited, and we will tell you it was a duplicate and when we first found it.

11.4 We are happy to provide a written reference confirming a report and its handling, for researchers who want one for a portfolio or an employer.

12.1 Security reports: security@gitaegis.com

12.2 Machine-readable policy: /.well-known/security.txt

12.3 Abuse that is not a vulnerability: support@gitaegis.com: see the Acceptable Use Policy.

12.4 Privacy questions: privacy@gitaegis.com

12.5 A postal address for Fahid Digital Ventures LLC is not published in this draft.

12.6 Related: Security · Acceptable Use Policy · Terms of Service · Privacy Policy · DPA