Security Advisories

Disclosure handled openly and on the record.

Published advisories, our coordinated disclosure policy, and a direct route for reporting a vulnerability in anything we have built.

Report a vulnerability

How to reach the security team

We do not run a bug bounty. We do respond to every report, and we credit reporters who want it.

security@sadhyata.com

Monitored by the security practice. PGP key available on request for sensitive reports.

One business day

Acknowledgement target for every report received, including ones that turn out not to be issues.

Safe harbour

Good-faith research on systems we operate will not result in legal action from us.

Client systems

For issues in a client-operated deployment we will coordinate the introduction rather than act unilaterally.

Policy

Coordinated disclosure, ninety days

Extended only where a fix genuinely requires it, and only with the reporter's agreement.

  1. 01

    Day 0

    Report received

    Send details to security@sadhyata.com. We acknowledge within one business day and assign a named handler.

  2. 02

    Days 1–5

    Triage and validation

    We reproduce the issue, assess exploitability against affected deployments, and confirm scope with you before anything is announced.

  3. 03

    Days 5–90

    Remediation

    A fix is developed, tested, and rolled out to affected clients. We keep the reporter updated at agreed intervals throughout.

  4. 04

    After remediation

    Coordinated publication

    An advisory is published with credit to the reporter, unless anonymity is requested. We do not publish before affected clients have patched.

Published

Advisory archive

Advisories affecting our own code or guidance. Third-party advisories are listed where we notified clients directly.

  1. Informational

    Guidance: rotating long-lived cloud access keys

    Advisory note for clients still using static access keys in CI. Includes a migration path to short-lived federated credentials and a detection query for remaining usage.

  2. Third party

    Upstream dependency advisory — affected clients notified

    A vulnerability in a widely used transitive dependency. All affected client deployments were identified from our SBOM inventory and patched within the agreed window.

  3. Informational

    Post-quantum readiness: inventory your cryptography now

    Migration timelines are longer than most organisations assume. Practical guidance on building a cryptographic inventory before selecting algorithms.

  4. Resolved

    Configuration hardening note for a legacy integration pattern

    A pattern used in older integration work could permit over-broad service permissions if deployed without the accompanying policy. Affected clients were contacted directly and remediated.

Response targets

What each severity commits us to

Published targets rather than best-effort language, measured from acknowledgement. We report against these in the advisory itself.

Critical

Paged 24/7
What it means
Remote exploitation with no authentication, or active exploitation observed
We acknowledge within
4 hours
We aim to remediate within
72 hours, with interim mitigation sooner

High

What it means
Privilege escalation or data exposure requiring some access
We acknowledge within
1 business day
We aim to remediate within
14 days

Medium

What it means
Exploitation needs unusual conditions or significant access
We acknowledge within
2 business days
We aim to remediate within
60 days

Low

What it means
Limited impact, or requires a highly improbable chain
We acknowledge within
5 business days
We aim to remediate within
Next scheduled release

Informational

What it means
Hardening opportunity with no direct exploitation path
We acknowledge within
5 business days
We aim to remediate within
Backlogged and prioritised normally

Questions

For researchers and for affected clients

The disclosure-window question is the one worth reading before you report.

Reporting to us

Do you offer a bug bounty?

We do not run a paid bounty programme. We do acknowledge every valid report, credit researchers publicly in the advisory where they wish to be named, and we will not pursue legal action against good-faith research conducted within the policy on this page. If a report leads to a material fix we will say so plainly in the advisory.

What counts as good-faith research?

Testing only against systems in scope, avoiding privacy violations and service degradation, not accessing or retaining more data than needed to demonstrate the issue, and giving us a reasonable window before disclosure. Social engineering of our staff, physical attacks and denial-of-service testing are out of scope.

How long before I can publish?

We ask for 90 days from acknowledgement, or until a fix is available and deployed, whichever comes first. If we need longer we will explain why and agree a revised date with you rather than simply asking again. If we go quiet for 14 days without explanation, treat that as agreement to publish.

Advisories we publish

Do you publish advisories for issues nobody reported externally?

Yes, where the issue affected a deployed client system and there was any plausible exposure. Publishing only externally-reported findings would give a misleading impression of how issues actually surface — most of ours come from our own scanning and review.

Will you notify us directly if we are affected?

Yes. Affected clients are contacted through the escalation path agreed at contract before the advisory is published, with the specific exposure for their deployment and the remediation status. The public advisory follows once affected clients have had a chance to act.

Concerned about something specific?

If you believe you have found an issue in a system we built, contact us directly rather than filing a general enquiry.