GSRA · Gdwyn Security Review AgentAbout the agent & its output
Display: E-ink
Design-stage security review
Gdwyn Security Review Agent
What GSRA is, what it does, and how every review it produces is shaped and presented.
Short name
GSRA
Reviews
A system’s written design, before it is built
Produces
A structured security audit with findings, fixes, tests, gates and a go / no-go verdict
Verdict01An overall go / no-go, and the things to fix first.
Findings02Numbered risks, each with evidence, fixes and proof.
Cross-checks03Contradictions in the documents, and framework coverage.
Target state04How data should be handled, and what to build.
Tests & gates05How fixes are proven, who owns them, and when to release.
Open questions06Decisions only named owners can make.
What GSRA is
01 · The agent
GSRA reviews a system’s design for security risk before it is built — and says what to change, and how to prove it changed.
[ In one paragraph ]
The Gdwyn Security Review Agent (GSRA) performs design-stage security reviews. It reads the written design of a system — scope documents, engineering plans, API specifications, schema dictionaries and architecture diagrams — and reports what the design says, leaves out or contradicts. Every problem becomes a numbered finding with a severity, the evidence from the documents, the exposure it creates, concrete fixes and the test that proves each fix. GSRA then turns the findings into a release path: a target architecture, an acceptance test plan, named owners, staged release gates and a go / no-go recommendation.
Finding problems at the design stage is the cheapest point to fix them: nothing has to be rebuilt, only rewritten.
[ What it is not ]
—
Not a penetration test. Nothing is tested against a running system.
—
Not a code review. It reads the design, not the implementation.
—
Not a legal opinion. Regulatory points are flagged for counsel.
—
Not a compliance assessment. Formal scope decisions stay with the accountable assessor.
—
Not proof of a vulnerability. Where a document wasn’t supplied, a finding is a gap to verify.
What it does
02 · From documents to verdict
01
Reads the design end to end
Every supplied document, including specifications, data dictionaries and diagrams — not just the summary.
02
States what it could not see
Documents that weren’t supplied are listed up front, so findings in those areas read as gaps to verify, not proven flaws.
03
Credits what is sound
Existing strengths are listed so they are preserved — while noting they are design commitments until tested.
04
Finds the risk between the controls
Trust placed in the wrong component, decisions left open, and places where documents disagree with each other.
05
Rates and maps every finding
A severity level, plus references to recognised frameworks (such as OWASP and ASVS) and relevant regulations, so each finding drops straight into a risk register.
06
Prescribes the fix and the proof
Numbered recommendations, and the acceptance evidence that shows each fix actually works.
07
Consolidates independent reviews
When other audits of the same documents exist, GSRA merges them: shared findings keep their ID, new ones get new IDs, and claims it cannot verify are softened rather than stated as fact.
08
Turns findings into a release path
Target architecture, adversarial tests, an owner register, staged release gates and a final go / no-go.
Shape of the output
03 · Six parts, always in this order
Every GSRA review moves from orientation, to the risks, to what “fixed” looks like, to how release is earned. Section numbers vary with the system, but the parts and their order don’t.
[ A · Orientation ]
Read first
A1
How to read this
The finding format, the severity scale, the frameworks used, the documents reviewed and not reviewed, and the design’s existing strengths.
Use it to calibrate before reading anything else.
A2
Executive summary
The overall recommendation and the short list of things to fix first.
Use it to brief leadership in two minutes.
[ B · Findings, by domain ]
The core
Findings are grouped into security domains. Domains appear only when the design gives reason to raise something in them; typical ones are:
Each finding follows the same shape — see part 04.
[ C · Cross-checks ]
C1
Document inconsistencies
Contradictions between or within the documents, and why each matters.
Use it to fix the documents, so no one approves a control that doesn’t exist.
C2
Framework coverage matrix
Each category of each framework, with the findings that touch it and a status note.
Use it to show auditors coverage, and spot thin areas.
[ D · Target state ]
D1
Data classification & handling
Classes of data, and for each: where it may flow, who may see it and how it must be stored.
Use it to decide what any field may do, everywhere.
D2
Target architecture & invariants
The enforcement chain every request should pass through, and the rules that must always hold.
Use it to design and review — and to test the rules as properties.
[ E · Proof & release ]
E1
Adversarial acceptance test plan
Attack scenarios, the expected secure result, and the findings each one proves.
Use it to define “done” for the security work.
E2
Owner & action register
Workstreams, the owner to nominate, the first deliverable and the findings each closes.
Use it to assign the work.
E3
Release gates
Staged gates with exit criteria. Each gate must close, with evidence, before the next opens.
Use it to run go / no-go reviews.
E4
Final release recommendation
What must not be authorised yet, what may proceed now, and what each gate unlocks.
[ F · Follow-up ]
F1
Questions for owners
Open decisions grouped by the team that has to answer them.
Use it to unblock fixes that depend on a decision.
F2
References
Standards and sources checked, with the date they were checked.
Anatomy of a finding
04 · Every finding has one shape
Findings are built from the same parts, in the same order, so they can be compared, assigned and tracked. The sample below is a generic template written for this page; lettered tags match the key beside it.
Illustrative sample · not from any review
Finding 07 / 32 CBlocks: Gate 1 · Before real user data
SEC-07AHighB
Collapse ▴K
Session tokens are stored in browser storage D
01 · What the plan says E
Design §3.2: the web app keeps the access token in localStorage “so it survives a page refresh”, and attaches it to every API call. Tokens last 30 days.
▲ Attack scenario G
An attacker gets one script to run on the app — through a rendered comment, say. The script reads the token and sends it out. The attacker now has the user’s session for a month, from any device.
02 · Why it exposes you F
—
Any script on the page can read browser storage, so a single XSS bug becomes account takeover.
—
A 30-day token gives a stolen session a long useful life.
03 · What to change H
R1
Keep sessions server-side. Use an opaque session ID in a Secure, HttpOnly, SameSite cookie that scripts cannot read.
R2
Shorten and rotate. Set an idle timeout and an absolute lifetime, and rotate the session ID at sign-in.
R3
Contain scripts. Add a strict Content Security Policy as defence in depth.
04 · Acceptance evidence I
A test page that runs injected script cannot read any credential. Sessions expire on schedule, and a revoked session is refused on the next request.
SEC-nn. Stable across revisions, and cited everywhere else in the review.
BSeverity
How bad it is if built as written. See part 05.
CPosition & gate
Its place in the review, and the release gate it must be closed before.
DTitle
The risk in one line.
EWhat the plan says
The design as written, with section references. The evidence.
FWhy it exposes you
The consequence. Sometimes headed Gaps.
GAttack scenario
Only where it helps: a concrete walk-through of the attack.
HWhat to change
Numbered recommendations, R1…Rn; strongest first where options are given.
IAcceptance evidence
The test or artefact that proves the fix works.
JFramework mapping
Framework and regulatory references for a risk register.
KCollapse
A reading control, not content. Every finding starts open.
Short findings may skip the headings and give a direct list of fixes; these appear under Detail.
Severity
05 · Four levels, shown as ink density
[ Scale ]
Default deadline
Critical
Likely to cause a reportable breach, regulatory breach or loss of funds or accounts if built as described.
Before build starts
High
Significant exposure, or a missing control a regulator, auditor or pen tester would flag.
Before real user data
Medium
Raises the likelihood or impact of other issues.
Before go-live
Low
Hygiene, consistency or documentation gap.
When convenient
A finding may also be rated Medium–High when it sits between two levels; it is counted with High.
[ Read carefully ]
Severity measures security risk. Project documents often use words like “critical” for delivery priority. A GSRA review calls out that difference when it matters — the two scales don’t line up.
GSRA writes each review as a Markdown document. The document is rendered as a review console in the GDWYN Ink Console style: two inks on paper, like an e-ink reader, with the labelled, always-oriented layout of a security command center. The same rendering works for any GSRA review.
Status bar 1
Title, scope & review details 2
3
Section index 4
Section title 5
SEC-016
SEC-02
SEC-03collapsed
Reading progress 7
[ Layout ]
1Status bar
Revision, reviewer, review mode, gate progress and date.
2Header
Subject, documents reviewed, revision and preparer.
3Posture strip
Count of findings at each severity, at a glance.
4Section index
Jumps between parts; a sticky tab strip on phones.
5Section
One part of the review at a time.
6Findings, top-down
Every finding open beneath its ID, in reading order. Collapse any, or all.
7Progress
Where you are in the review, like a reader’s location bar.
[ Console pages ]
Which part goes where
P1
Overview
Verdict, fix-first list, a domain-by-severity grid, the severity scale, existing strengths, frameworks and scope limits.
P2
Findings
All findings in order, grouped by domain, with severity filters and expand / collapse all.
P3
Framework coverage
One map per framework; finding IDs are chips that jump to the finding.
P4
Controls & testing
Data classes, the enforcement chain drawn step by step, invariants and the acceptance test plan.
P5
Release gates
The final recommendation, then each gate’s exit criteria as a checklist with a readiness count.
P6
Owners & questions
The action register and open questions grouped by owner.
P7
Annexes
Document inconsistencies, domain-specific tables and references.
Any finding ID anywhere in the console is a link to that finding.
Terms
07 · Used in every review
Finding
One security risk in the design, with an ID, severity, evidence, fixes and proof.
Domain
A group of findings about one area of the system.
Acceptance evidence
The test result or artefact that shows a fix works.
Framework mapping
The categories in standards such as OWASP and ASVS that a finding relates to.
Gate
A release checkpoint with exit criteria; it closes only with evidence.
Invariant
A rule that must always hold, whatever the request, user or failure.
Enforcement chain
The ordered checks every request passes through, each one recorded.
Data class
A category of data with its own rules for where it may go and how it’s stored.
Gap to verify
A risk in an area whose documents weren’t supplied — not proven, but not cleared.
Consolidation
Merging independent audits of the same documents into one review.
Revision
A new version of a review; finding IDs carry over between revisions.
Go / no-go
The final recommendation on what may proceed, and when.
Limits
08 · Read before relying on a review
—
A review covers the documents as written on the date stated. It doesn’t replace a threat-modelling workshop, code review or penetration test of the built system.
—
Strengths a design describes are commitments, not verified controls, until they are tested.
—
Regulatory references are flagged for legal confirmation, not given as legal advice.
—
Standards are checked on the review date; verify current versions before relying on them.