Authentication vs. authorization
Authentication identifies the principal. Authorization decides whether that principal may perform a specific action on a particular object.
Avoid: Logged-in users are secure.
SECURITY WRITING / VERSION 1.0 / 2026-11-09
Security reports
engineers can use.
A consistent reporting format for security findings, threat boundaries, reproduction steps and actionable engineering fixes.
SECURITY TERMINOLOGY / REPORTING
Terms that shouldn't be interchangeable.
Vulnerability vs. exposure
Call an issue a confirmed vulnerability only when the unsafe behavior and impact are reproducible. Label weaker signals as potential exposure.
Avoid: Critical vulnerability found from a version string alone.
Exploit vs. proof of concept
Explain whether the path was demonstrated, safely simulated or reasoned about. Include prerequisites and authorization.
Avoid: Full exploit verified without a test record.
Compromise vs. elevated risk
Use compromised only for substantiated unauthorized control or data access. Record scope and timestamp.
Avoid: Exposed endpoint means the system was hacked.
Encryption vs. access control
Name the data, keys, endpoint and trust boundary. Encryption does not replace per-request authorization.
Avoid: AES means this API cannot be abused.
Attestation vs. device trust
App Attest and Play Integrity provide narrow integrity signals, not a general guarantee that devices or users are safe.
Avoid: Attestation prevents all fraud.
FINDING FORMAT
Make a report actionable.
01 / IDENTITY
Report identifier, version, scope owner and assessment window
02 / CLAIM
Affected asset, precise conditions, observed result and evidence reference
03 / IMPACT
What access or action is actually possible, and what remains unproven
04 / FIX
Enforcement point, expected invariant, owner and implementation notes
05 / RETEST
Negative-path reproduction before and after, including unresolved limitations
Severity is contextual.
Describe exposure, privileges, exploit prerequisites, affected data and compensating controls. Use a scoring system only when its version, inputs and environmental assumptions are documented. Don't invent CVSS scores to decorate an article.
Separate evidence from prediction.
A screenshot, a synthetic lab, an unauthorized user response and a hypothetical attack path are different evidence classes. Label the environment, verification status, limitations and reproduction method.
Publish only what you're authorized to disclose.
Remove secrets, personal data, customer identifiers and implementation details that require consent. A client may approve the technical facts but not their name or logo; those permissions must be documented separately.