// TRACK_01 :: BLUE_SIDE
BUILD ONE SERVICE.
SECURE IT AGAINST EVERYONE.
You are not building a bank. You are building one service inside one, against a published interface contract, with a fixed list of security requirements and a fixed list of events it must emit. Four people can finish it. Then two Red teams try to break it.
LIT
PROPOSAL REQUIRED
// Your_Mission
One cell.
Built twice.
Build and secure one JengaBank application against its published brief.
UP TO 10 PROPOSALS PER BRIEF
TOP 3 ADVANCE
+1 RESERVE
Every brief is built twice, by two different teams, in two separate enterprises. The comparison between them is part of what is judged.
// The_Catalogue
Nine briefs.
Pick what you can already do.
Choose a brief that matches what your team can already do. Every requirement below is checkable by a judge.
// SECURITY_IT_MUST_GET_RIGHT
- Server-side authorisation on every request.
- Session lifetime, invalidation and secure cookie attributes.
- A cooling-off period or step-up authentication before a newly added beneficiary can receive funds.
- Defence against injection, cross-site scripting, cross-site request forgery, insecure direct object reference and open redirect.
- Rate limiting and lockout on all authentication and money-movement paths.
- Statements generated server-side with authorisation checked at generation, not merely at link time.
- A full audit trail the customer can retrieve.
// WHAT_RED_WILL_TRY
- Authentication bypass, session fixation and hijacking.
- Horizontal privilege escalation between customers.
- Business-logic abuse of the beneficiary and transfer flow.
- Forced browsing to unlinked endpoints.
// SECURITY_IT_MUST_GET_RIGHT
- Device registration and binding so a token issued to one device cannot be replayed from another.
- Short-lived access tokens with refresh-token rotation and reuse detection.
- Transaction signing or step-up confirmation independent of the session token.
- Idempotency keys on every state-changing endpoint.
- Strict schema validation that rejects unknown fields rather than ignoring them.
- Per-device and per-account rate limiting.
- No sensitive data in URLs, logs or error messages.
// WHAT_RED_WILL_TRY
- Token theft and replay across devices.
- Refresh-token abuse.
- Idempotency and race-condition attacks on transfers.
- Mass assignment.
- API enumeration for unprotected endpoints.
// SECURITY_IT_MUST_GET_RIGHT
- Credential storage using a modern memory-hard password hash with per-user salt and a breached-password check.
- Multi-factor authentication with at least two second factors, plus recovery codes issued once and stored hashed.
- Signed short-lived tokens with audience and issuer claims, key rotation, and a published JWKS endpoint.
- Token revocation and introspection so a compromised session ends enterprise-wide within seconds.
- Password reset that does not disclose account existence, uses single-use time-limited tokens and invalidates all sessions.
- Progressive lockout resistant to both targeted brute force and credential-stuffing sprays.
- Risk signals on every authentication: new device, new location, impossible travel, unusual hour: emitted even when the login is allowed.
- A tamper-evident audit log of every identity event.
// WHAT_RED_WILL_TRY
- Credential stuffing.
- User enumeration through timing or message differences.
- MFA bypass through flow manipulation.
- Token forgery and algorithm confusion.
- Password-reset token prediction or reuse.
- Race conditions in enrolment.
// SECURITY_IT_MUST_GET_RIGHT
- A double-entry ledger where balance is derived from entries and never from a mutable field.
- Atomic, isolated transfer execution provably safe under concurrent requests.
- Idempotency on every payment instruction with a defined retention window.
- Per-transaction, daily and velocity limits evaluated server-side.
- A rules-based fraud check producing allow, review or block with a recorded reason, and a reviewable queue.
- Maker-checker approval above a defined threshold where the approver may not be the initiator.
- Reversals and refunds as compensating entries, never as mutation of history.
- An append-only transaction log with independently verifiable sequence integrity.
- End-of-day reconciliation that proves the ledger balances.
// WHAT_RED_WILL_TRY
- Race conditions and time-of-check-to-time-of-use attacks on balance.
- Negative and precision-abuse amounts.
- Currency and rounding manipulation.
- Replay of payment instructions.
- Limit bypass through decomposition.
- Forging or replaying the settlement webhook.
// SECURITY_IT_MUST_GET_RIGHT
- Stage transitions enforced server-side and impossible to skip by manipulating client state.
- Document upload with content-type verified by inspection rather than by extension, size limits, malware scanning, and storage in the private bucket.
- Documents served only through authorised, short-lived, single-use links with non-guessable references.
- A deterministic credit-scoring component with a recorded input snapshot so any decision can be reproduced.
- Segregation of duties between applicant, assessor and approver.
- An approval authority matrix by amount, enforced in code, with an escalation path.
- Disbursement issued only after approval, signed, idempotent, and impossible to trigger from the applicant's session.
- Defined retention and deletion for the personal and financial documents collected.
// WHAT_RED_WILL_TRY
- Workflow-stage skipping.
- Insecure direct object reference across applicants.
- Malicious file upload and path traversal.
- Tampering with declared income or score inputs.
- Privilege escalation from applicant to assessor or approver.
// SECURITY_IT_MUST_GET_RIGHT
- Role-based access control with at least four staff roles whose permissions genuinely differ, enforced server-side for every action and never merely hidden in the interface.
- Maker-checker on every high-impact action, with a different and more senior checker.
- Mandatory structured reason codes on every privileged action.
- Just-in-time elevation, time-boxed and automatically revoked.
- Data minimisation by role, with masked account and identity numbers and unmasking as a separately audited action.
- Administrative access restricted by network origin.
- Session controls suited to a shared workstation: short idle timeout, explicit lock, concurrent-session limits.
- A tamper-evident audit log viewable by an auditor role that cannot modify customer data.
- Detection and alerting on insider-abuse patterns: bulk record access, out-of-hours activity, repeated access to one customer, and self-servicing of an employee's own accounts.
// WHAT_RED_WILL_TRY
- Privilege escalation between staff roles.
- Forced browsing to administrative functions.
- Maker-checker bypass through self-approval or replay.
- Mass data extraction through search and export.
- Abuse of elevation flows.
// SECURITY_IT_MUST_GET_RIGHT
- Ticket lifecycle with an immutable conversation thread.
- Two-sided messaging where internal notes are provably invisible to the customer.
- Attachment upload from both sides with type verification by inspection, size limits, malware scanning, and rendering that cannot execute in the browser.
- Structured customer identity verification before any account-affecting action, with method and outcome recorded on the ticket.
- Output encoding everywhere customer-supplied text is rendered, including the agent interface: the higher-value cross-site scripting target.
- Rate limiting on ticket and message creation.
- A defined, enforced boundary: anything touching money or credentials is handed to the back-office portal rather than performed here.
- Detection and masking at ingestion of credentials or card numbers pasted into a ticket.
// WHAT_RED_WILL_TRY
- Stored cross-site scripting aimed at agents.
- Insecure direct object reference across tickets.
- Leakage of internal notes into the customer view.
- Malicious attachments.
- Social-engineering flows that trick the system into treating an unverified caller as verified.
// SECURITY_IT_MUST_GET_RIGHT
- Scoring that consumes the payments ledger rather than duplicating it.
- Analyst role-based access control and case-level authorisation.
- Tamper-evident case history where decisions cannot be rewritten.
- Customer notification that does not itself disclose account detail.
- An analyst feedback loop that the customer cannot poison, and integrity protection on the rule set itself.
// WHAT_RED_WILL_TRY
- Score evasion through transaction shaping.
- Case tampering.
- Suppression of alerts.
- Poisoning of the feedback loop.
// SECURITY_IT_MUST_GET_RIGHT
- Authorisation checked at generation time, not at link time.
- Short-lived signed document links that are not guessable or enumerable.
- Template rendering safe against injection.
- Data minimisation in every message body.
- Rate limiting, and a full delivery audit trail.
// WHAT_RED_WILL_TRY
- Account enumeration through notification behaviour.
- Statement link prediction.
- Template injection.
- Notification flooding used as cover for other activity.
Full application briefs, with every security requirement a judge will check, are issued in the welcome pack when registration completes.
// Every_Blue_Cell
Eight rules.
No exceptions.
✓
One container image per service, built by the provided pipeline, running as a non-root user with no privileged mode and no host mounts.
✓
A single HTTP port from the PORT environment variable, with GET /healthz, GET /readyz, and a machine-readable GET /openapi.json that matches the implementation.
✓
Configuration from environment variables and mounted secrets. A credential in the repository is an automatic finding, whether or not a Red Team discovers it.
✓
Stateless services: all persistent state in the provided database or bucket: with idempotent migrations applied on deploy.
✓
Transport security everywhere. Authorisation evaluated server-side on every request against the acting principal, never inferred from a client-supplied role.
✓
Input validated against an explicit schema at the boundary, with unknown fields rejected rather than ignored. Errors must not disclose stack traces, queries, versions or internal hostnames.
✓
Dependencies pinned and scanned, free of known critical vulnerabilities at submission. Rate limiting on authentication, search, export and any expensive operation.
✓
Telemetry in the common envelope, emitted within five seconds of the action. Missing telemetry is scored as a missing security control, not as a documentation gap.
HEADINGS ARE NOT OPTIONAL :: Use the section numbers and titles below as your document headings, in order, exactly as written, for example 08 Threat Model. The platform reads headings to locate each section before a judge opens the file. A section under a different title, or merged into another, can be read as missing and scored as missing.
// Proposal_Sections
Twelve core sections.
With weights.
01
Executive Summary Framing
One page. What the team is building, for which brief, why it matters, and what will exist at the end of the build phase.
02
Problem Statement 10%
The specific security problem this component exists to solve, in its enterprise context. Not "cyber attacks are increasing".
03
Objectives
Three to six objectives, each specific and verifiable. "Implement MFA with recovery" is an objective; "improve security" is not.
04
Proposed System 15%
What the service does, its main flows, and its boundaries: including what it deliberately does not do.
05
System Significance 15%
Why this component failing would matter to JengaBank, and what an attacker gains by compromising it.
06
Functional Requirements 15%
A numbered, testable list covering every mandatory capability in the brief, plus the team's own additions marked as such. Must include a compliance table mapping every mandatory capability and every mandatory endpoint to the requirement that covers it.
07
Non-functional Requirements 15%
Performance, availability, scalability, maintainability and operability targets, with numbers attached.
08
Threat Model 20%
Assets, trust boundaries, actors, attack surface, threats enumerated using a named method (STRIDE, attack trees or equivalent), and the risks accepted.
09
Security Objectives 20%
The controls that answer the threat model, each traced to the threat it mitigates and to a recognised framework reference.
10
Proposed Architecture Diagram 15%
At least one component diagram and one data-flow diagram with trust boundaries marked, embedded as legible images, each with a text description beneath it.
11
Technology Stack 15%
Languages, frameworks, libraries, data stores and any AI models, with a justification for each significant choice and a note on its security posture.
12
Development Timeline 10%
Week-by-week plan across the build window, with named owners, dependencies and milestones. Must include time for testing and documentation.
// Additional_For_This_Track
Ten additional sections.
- Interface compliance table mapping every mandatory endpoint to a designed route, with the request and response shape.
- Data model with a sensitive-data inventory: for each field, its classification, whether it is encrypted, whether it appears in logs, and its retention.
- Authentication and authorisation design, including how the cell consumes the enterprise identity service and how it evaluates authorisation on every request.
- Session management design where the cell holds sessions: lifetime, invalidation, storage and binding.
- Input validation and output encoding strategy, stated as a rule the whole codebase follows rather than a per-endpoint intention.
- At least six abuse cases written from the attacker's point of view, each with the control that defeats it, reflecting the Red team exposure named in the brief.
- Telemetry plan listing every event the cell will emit, its category, its severity and the fields it carries.
- Dependency and supply-chain plan: how dependencies are pinned, scanned and updated during the build window.
- Target OWASP ASVS level, with a note on the requirements the team expects to meet and the ones it will not.
- Integration contract with the cells this one consumes or is consumed by.
UPLOAD FORMAT :: Attach a cover page, declaration of originality, and AI use statement. Missing any of the three is returned as incomplete. PDF only, selectable text, 12 to 20 pages excluding cover, contents, references and appendices. A4, margins >= 2 cm, body >= 11 pt, spacing >= 1.15, max 25 MB, English, no password or encryption. Filename: JS26_<ENTERPRISE>_<CELL>_<TEAMID>_<TYPE>_v<N>.pdf.
AI USE :: Editing your own text, diagrams from your own content, and human-verified research assistance are permitted when declared. Generating the threat model or security design without team authorship, unread citations, or undeclared use is not permitted.
// Before_You_Register
Ready in thirty minutes.
Or losing days.
✓Full legal name of every member, exactly as on their identity document.
✓Identity document per member showing date of birth. PDF, JPG or PNG, under 5 MB, photographed in good light with the whole document in frame.
✓Email per member, institutional if you have one.
✓GitHub or GitLab handle per member.
✓If enrolled: student number, institution, programme and year of study.
✓Captain and one deputy: phone number in international format, for example +254712345678.
✓Team name, three to forty characters.
✓Ranked track preferences for your side.
✓Skills declaration, 100 to 1500 characters, honestly describing what the team has built before. Overstating it earns you a brief you cannot complete.
// Final_Word
Pick your brief.
Start the threat model tonight.
> ./register --track=application-blue --team=4