Security

Where it runs

• The application runs on Vercel and the database on Neon, both in Amazon Web Services’ Ohio region. Everything is held in the United States.
• Every connection is encrypted, and browsers are told to refuse an unencrypted one. Data is encrypted at rest by the database and storage providers.
• The database keeps point-in-time history for six hours on its current plan, so it can be restored to any moment in that window.

What runs on your computers

• Nothing is installed for administrators, exam reviewers, proctors, assessors, certifying officials or subject-matter experts: every screen is a web page over an encrypted connection. No browser extension, no agent, no script on city machines.
• The one exception is stated plainly: a written examination sat under lockdown will use Bugle’s secure client, a signed desktop application the candidate’s computer runs for the sitting (not yet available, below). A department that sits its written examinations in a proctored session on video can choose the browser instead.
• A department may limit sign-in and sittings to its own network addresses, and may require two-step sign-in of the roles it chooses.

Each department sealed from every other

Every table that holds a department’s information is protected by row-level security inside the database, forced on for the application’s own connection. A query made outside a department’s context returns nothing — even if a fault in the application asked for more.

It is tested by attack. Connected as the application itself, one department asks for another’s rows in every table that holds them, by their exact identifiers — to read them, change them and delete them — and asks every service that takes an identifier from a request for another department’s lists, appeals, records, audit trail, recordings and uploads. Every request is refused, and the tests fail if one ever is not.

Accounts

• Passwords are stored only as salted scrypt hashes.
• Two-step sign-in with an authenticator app. Each code is accepted once. Ten single-use recovery codes are issued for a lost phone and kept only as hashes, and the authenticator secret is encrypted at rest.
• A department can require two-step sign-in of the roles it chooses; a member without it opens nothing until it is set up. Bugle’s own staff always use it.
• Certifying a list, changing a score, deciding an appeal or a correction, exporting a record, placing a legal hold, deciding a disposal and changing who holds a seat each ask the person to confirm who they are again, if they have not in the last fifteen minutes.
• A lost second factor is reset only by the department’s administrator or by Bugle, with how the person was confirmed on the record.
• Single sign-on through OpenID Connect, with the identity provider a deployment is configured for. An account stays tied to the identity it first signed on with, and an address the identity provider has not verified is refused.
• Repeated failed sign-ins are throttled by network address, and lock the account. Password-reset requests are limited for each address and each network.
• Session cookies are HTTP-only and secure. Signing out, setting or changing a password, or turning on two-step sign-in ends every session of the account on the server — a copied session stops working too. An administrator can sign a member out everywhere, and switching an account off does the same.
• Pages carry a content security policy that limits scripts, styles and connections to the service’s own address, and refuse to be framed by any other site.
• A set-password link works once, and only the newest one issued works.
• Every sign-in and security event is recorded with its time, network address and browser.

Who can do what

• Every high-risk action is its own permission, held by named roles: viewing answer keys, exporting the item bank, publishing a form, editing a blueprint, approving a question, viewing demographics, viewing accommodations, changing a score, resolving an appeal, certifying a list, managing retention, placing a legal hold, managing users and reading the audit record. Each is checked by the service that does the work, not only by the screen that offers it.
• Nobody holds both halves of a two-person decision: a correction to a key and a disposal of records are each proposed by one person and decided by another.
• Every opening of examination content, candidates’ demographics or accommodations, and every export, is written to the department’s access record under the person’s name and role.
• Application logs never carry passwords, keys or session cookies, and never a candidate’s answers, transcripts, self-identification or accommodations: the logger withholds them, whatever part of the service calls it.

Examination integrity

• Frozen forms. A published form is frozen and hashed: nothing in it is edited and nothing is added to it afterwards, and its hash is checked when a candidate starts it and again when it is scored. What a candidate saw can be shown exactly. A key found wrong later is corrected by a recorded decision — proposed by one person, decided by the official who certifies results — and every candidate is rescored under it; the form itself is never changed.
• A record that shows tampering. The audit trail is append-only and hash-chained: each entry commits to the one before it, so an entry altered, removed, or written around the chain breaks it. Every department’s chain is checked daily and each check is kept, which also shows entries removed from its end since the last check.
• Proctored sittings. In a proctored session a candidate starts only after a named proctor has checked them in, confirmed who they are and told them to begin. A proctor can pause an exam — the clock stops and the time is given back — report an irregularity, or end a sitting in an emergency, and closes the session with a count they sign. Every step is on the record as it was taken.
• Need to know. A department’s question text, answer keys and scenario content are opened only by the Bugle staff who build examinations, the exam reviewers a department names, the assessors scoring an attempt, and the certifying official deciding an appeal or a correction to a key — not by Bugle’s sales, finance or marketing staff. Each opening of a department’s questions outside a sitting is written to its access record under the person’s name and role. The starter questions and scenarios Bugle ships are its own and appear in its demonstration department, so one a department puts on a scored form unchanged is known outside the department.
• Nobody judges their own examination. A person sitting a process is not appointed its reviewer, assessor or certifying official, is put on none of its panels, and is shown none of its questions.
• Blind scoring. Assessors score an anonymous code, never a name.
• Fireground runs decided by the scenario as written. Every branch a simulation can take is written in advance and signed off with it; which one a run takes is a fixed rule applied to the candidate’s orders and the clock, the same for everybody. Each run keeps a chained record of everything delivered and why, each order given in answer, each decision, and how it ended — and it can be replayed from the published form and those orders alone, coming out the same row for row.
• Every question has a history. Who wrote it or asked for it to be drafted, who sent it back and why, what each edit changed, who approved it, and every doubt raised about its source and how it was settled — kept, and never edited. A drafted question is never approved without a person’s review.
• Documents are read on Bugle’s own servers. The words of a department’s guidelines and agreements, scanned copies included, are taken out on Bugle’s own servers, without sending the documents to any other service to be read.
• Uploaded documents are material, never instructions. A file is identified by its own contents, not its name: programs, scripts, macro-enabled Word files, PDFs that run code or carry attachments, and password-protected or damaged files are refused before anything is stored. Text in a document that is addressed to software rather than a reader is shown to the department and held back, and whatever reads a department’s document treats it as material to work on, never instructions to follow.
• The secure client. Bugle Secure Exam, a desktop client that holds the computer to the examination, is being prepared for release and is not yet available to departments. A form can already be set to require it, and the server then serves that form only to a live client session.
• Results checked before release. Before a department sees a score, Bugle’s coordinator runs a check: every submitted attempt scored and none left open, every item with a scoreable key, every score recomputed from the frozen form and matched, every simulation run replayed from its record, and every rating on every panel finalized — with irregularities and item behavior flagged for review.

Policies, audits and questionnaires

Bugle keeps written policies for incident response, business continuity, disaster recovery, access control, secure development, vulnerability management, change management, data retention, and backup and recovery, and an inventory of the companies that process a department’s data for it. A department’s reviewers may have them on request, with answers to their security questionnaire, from the Trust Center. Bugle holds no security certification and has not been independently audited or penetration-tested; its own assessment against the SOC 2 criteria, with what is not yet in place, is available on request.

For an IT office reviewing against a control catalogue — NIST SP 800-53, the CJIS Security Policy, a state program — Bugle keeps a readiness statement in the same shape: each control family, what is in place and where it is in the code, and what is not in place, named as a gap. It, too, is available from the Trust Center. Every statement in it names the code or document that makes it true, and the tests that hold it there run on every change.

Reporting a vulnerability

If you find a weakness, write to charles@bugleassessments.com with what you found and how to reproduce it. Please do not access anyone else’s data, disrupt an examination, or publish before we have fixed it. We reply to every report, and we will not pursue anyone who reports in good faith and follows these rules. The same contact is published at /.well-known/security.txt.