Question 1

What is responsible disclosure, and how do bug bounties work?

Accepted Answer

Responsible disclosure is reporting a security vulnerability **to the affected organisation first**, giving them time to fix it before details become public. A bug bounty programme is the formalised, paid version — and the distinction between them matters legally as much as practically.

**Why coordination exists at all.** Publishing a vulnerability immediately gives attackers a working exploit against unpatched systems. Never publishing removes the pressure to fix and leaves users unable to assess their own risk. **Coordinated disclosure is the compromise**: report privately, agree a timeline, publish afterwards.

**How it usually runs:**

**Find the policy.** Look for a `security.txt` file, a security page, or a bounty platform listing. This establishes what is authorised.

**Report privately**, with clear reproduction steps, impact assessment and proof of concept — and **no more access than needed to demonstrate it**. Downloading a database to prove you could is where researchers get into serious trouble.

**Agree a timeline.** Ninety days is the common default, with extensions for genuinely complex fixes and shortening if the issue is being exploited.

**Coordinate publication**, often with a CVE identifier and credit to the reporter.

**How bounties differ:** they define **scope** precisely — which domains and systems are in and out — set severity-based payment tiers, and, crucially, provide a **safe harbour** statement undertaking not to pursue legal action for good-faith research within scope.

**Why the legal position matters.** Computer misuse laws in many countries criminalise unauthorised access with **no research exemption**. Researchers acting in good faith have faced prosecution and legal threats. A published policy with safe harbour is what converts an offence into authorised testing — **so read the scope, and stay inside it.**

**For organisations:** publish a security contact even with no bounty; acknowledge reports quickly, since silence is the commonest reason researchers go public; never threaten a good-faith reporter, which is reputationally disastrous; and give credit, which is frequently valued as much as payment.

General information, not legal advice.

Question 2

How should application secrets actually be managed?

Accepted Answer

Kept out of source code entirely, injected at runtime, scoped narrowly, and rotatable without a deployment — and the reason this matters is that a secret committed to a repository is permanently

Question 3

What should you actually log, and what should you never log?

Accepted Answer

Log what you would need to diagnose a problem you cannot reproduce — and never log anything that turns your log store into a liability. Most logging is written for the moment it is added rather than

Question 4

What is a blameless postmortem?

Accepted Answer

A review after an incident that focuses on understanding what made the failure possible rather than on identifying who caused it — and the reason it works is practical rather than cultural

Question 5

Why does documentation always go out of date?

Accepted Answer

Because documentation and the code it describes are coupled in meaning but decoupled in enforcement — nothing breaks when they diverge, so they diverge. The core mechanism. Code has a merciless

Question 6

What is a feature flag?

Accepted Answer

A feature flag (or feature toggle) is a conditional in code allowing behaviour to be changed without deploying new code. The feature exists in the deployed application, and a configuration value

Question 7

What makes a good API design?

Accepted Answer

Predictability above cleverness — a good API is one where a developer can guess correctly what something is called and how it behaves, because they will guess far more often than they will read the

Related Questions