insa-check-core 0.1.0

package/dist/content/en.js

@@ -0,0 +1,722 @@
+/*
+ * English guided-review content for every Annex B item, plus the strings of the manual-review flow.
+ * To add a language, copy this file (e.g. am.ts), translate the values, keep the keys, and register
+ * it in content/index.ts. Item numbers and placeholders ({name}) must stay unchanged.
+ *
+ * References cite SWMS v1.0 (Secure Website Management Standard), CMCSRS v2.0 (Critical Mass Cyber Security
+ * Requirement Standard) and SSDMS v1.0 (Secure Software Development and Management Standard).
+ *
+ * Steps marked "staging" can disrupt a live service or change data: run them on a test copy.
+ */
+const STAGING = "Use a staging/test copy, never production, and only with written authorization.";
+export const EN = {
+    locale: "en",
+    language: "English",
+    ui: {
+        manualReviewTitle: "Manual review",
+        authorizationWarning: "Only perform these tests on systems you own or are explicitly authorized to test. Many steps log in, change accounts, replay sessions or send unusual input; doing this without permission may be illegal. Prefer a staging copy for anything that changes data.",
+        progress: "{reviewed} of {total} manual items reviewed",
+        verdict: { pass: "Pass", fail: "Fail", "not-applicable": "Not applicable", untested: "Untested" },
+        whatToCheck: "What to check",
+        howToTest: "How to test",
+        evidenceToRecord: "Evidence to record",
+        terms: "Terms explained",
+        references: "INSA requirements",
+        automatedResult: "Automated result",
+        verdictLabel: "Verdict",
+        note: "Reviewer note",
+        evidenceText: "Evidence (paste text, mask secrets)",
+        screenshots: "Screenshots",
+        addScreenshot: "Add screenshot",
+        removeScreenshot: "Remove",
+        screenshotTooLarge: "{name} is larger than {max} MB and was not added.",
+        screenshotWrongType: "{name} is not a PNG, JPEG, WebP or GIF image and was not added.",
+        saved: "Saved",
+        saving: "Saving…",
+        filterAll: "All",
+        filterPending: "Pending",
+        filterReviewed: "Reviewed",
+        backToReport: "Back to report",
+        startReview: "Manual review",
+        reviewer: "Reviewer",
+        reviewedAt: "Reviewed",
+        evidenceAttached: "{count} screenshot(s)",
+        evidenceTextAttached: "evidence text",
+        noManualItems: "This report has no items that need manual review.",
+        storageNotice: "Notes and screenshots are saved only in this browser (IndexedDB), are not encrypted, and are never sent to the server. Export JSON to back them up; the export includes screenshots.",
+        readinessIncomplete: "INCOMPLETE: {pending} item(s) still require manual review",
+        readinessErrors: "INCOMPLETE: {error} automated check(s) did not complete and must be re-run or reviewed",
+        readinessFailures: "COMPLETE: {fail} item(s) failed",
+        readinessClean: "COMPLETE: every item passed or is not applicable",
+        readinessPendingLine: "{pending} item(s) still require manual review.",
+        readinessNonePending: "No items are waiting for manual review.",
+        readinessNeedsNote: "INCOMPLETE: {count} Fail or Not applicable verdict(s) need a reviewer note",
+        readinessNeedsNoteLine: "{count} Fail or Not applicable verdict(s) need a reviewer note before the report is complete.",
+        readinessCarriedLine: "{count} verdict(s) were carried from an earlier report; re-confirm them.",
+        carriedFrom: "carried from the report of {date}",
+        historyCount: "{count} earlier change(s)",
+        cliIntro: "Guided manual review: {count} item(s) to go through. Answers are saved after each item; press q to stop and resume later with --resume.",
+        cliConfirmAuthorization: "Are you authorized to test this system? (y/N) ",
+        cliItemHeader: "[{position}/{count}] #{id} {title}",
+        cliVerdictPrompt: "Verdict: [p]ass, [f]ail, [n]ot applicable, [u]ntested, [s]kip, [q]uit",
+        cliKeepCurrent: "Enter keeps: {current}",
+        cliNotePrompt: "Note",
+        cliEvidencePrompt: "Evidence text",
+        cliScreenshotPrompt: "Screenshot file path (optional)",
+        cliSavedTo: "Saved to {file}",
+        cliStopped: "Stopped. Resume with: insa-check manual --report {file} --resume",
+        cliFinished: "Manual review finished.",
+        cliNothingToReview: "Nothing to review: every manual item already has a verdict. Run without --resume to revisit them.",
+    },
+    items: {
+        // --- Information Disclosure -----------------------------------------------------
+        "1": {
+            guidance: "Files left in the web root (backups, version-control folders, configuration, installers) can expose source code, passwords or database dumps.",
+            howToTest: [
+                "Request common leftovers: /.git/HEAD, /.env, /backup.zip, /db.sql, /index.php.bak, /web.config.old, /phpinfo.php.",
+                "Ask the administrator for a listing of the web root and look for *.bak, *.old, *.zip, *.sql, *.swp and files ending in ~.",
+                "Confirm the deployment copies only the built site, not the whole repository or developer files.",
+            ],
+            evidencePrompt: "Each URL that returned a file (status code, size, what it contained). Do not paste secrets.",
+            terms: [{ term: "Web root", meaning: "The folder whose files the web server makes public." }],
+        },
+        "2": {
+            guidance: "When a folder has no index page, some servers list every file in it, revealing files that were never meant to be linked.",
+            howToTest: [
+                "Open folders seen in the page source with a trailing slash, e.g. /images/, /uploads/, /assets/, /files/.",
+                "A page titled \"Index of /…\" or a plain list of files means directory listing is enabled.",
+                "Check the server configuration: Apache \"Options -Indexes\", nginx \"autoindex off\", IIS Directory Browsing disabled.",
+            ],
+            evidencePrompt: "URLs that showed a listing, or the configuration line that disables listings.",
+        },
+        "3": {
+            guidance: "Debug pages and debug modes reveal internals (stack traces, settings, SQL, environment variables) and some even allow running code.",
+            howToTest: [
+                "Request common debug endpoints: /phpinfo.php, /server-status, /server-info, /elmah.axd, /trace.axd, /actuator, /_profiler, /debug, /console.",
+                "Trigger an error (a non-existent page, a letter where a number is expected) and see whether a detailed debug page appears.",
+                "Confirm with the administrator that debug mode is off in production (e.g. Django DEBUG = False, Laravel APP_DEBUG=false, ASP.NET customErrors on).",
+            ],
+            evidencePrompt: "Endpoints tried and their responses; the production debug setting.",
+        },
+        "4": {
+            guidance: "Users should see generic error messages. Detailed errors (stack traces, SQL, file paths, versions) help attackers, and logs must not contain sensitive data.",
+            howToTest: [
+                "Send malformed input: a single quote ' in search fields, letters in numeric IDs, very long values, invalid dates.",
+                "Open a page that does not exist and look at the 404 page.",
+                "Look for stack traces, SQL fragments, server file paths, and framework or version strings in the responses.",
+                "Ask for a sample of application logs and check they contain no passwords, card numbers or session tokens.",
+            ],
+            evidencePrompt: "The input that caused a detailed error and what it revealed (mask any secrets).",
+            terms: [{ term: "Stack trace", meaning: "A technical listing of the code that was running when an error happened." }],
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 9 (p. 50): the developer must handle all errors and exceptions.",
+            ],
+        },
+        "5": {
+            guidance: "robots.txt is public. Paths listed under Disallow to \"hide\" admin or private areas actually advertise them.",
+            howToTest: [
+                "Open /robots.txt.",
+                "For each Disallow line, consider whether it reveals sensitive areas (admin panels, backups, internal tools, exports).",
+                "Open those paths without logging in; they must still require authentication.",
+            ],
+            evidencePrompt: "Sensitive Disallow entries and whether each path was protected.",
+            terms: [{ term: "robots.txt", meaning: "A public file telling search engines what not to index. It is not access control." }],
+        },
+        "6": {
+            guidance: "Page source and JavaScript are visible to everyone. Comments, API keys, passwords or internal hostnames left there are exposed.",
+            howToTest: [
+                "View the source of the main pages (Ctrl+U) and search for <!--, TODO, password, key, token, secret, api.",
+                "Open the linked .js files, including any .map source-map files, and search for the same words.",
+                "Look for internal URLs, staging hostnames, developer names or e-mail addresses.",
+            ],
+            evidencePrompt: "File or URL and the kind of data exposed. Do not paste the secret itself.",
+            terms: [{ term: "Source map", meaning: "A .map file that lets browsers show the original source code; it can expose the full code." }],
+            references: [
+                "Related (IoT scope) CMCSRS v2.0 §6.31 f.3: authenticate identities without hard-coding passwords, tokens or other secrets.",
+                "SSDMS v1.0 §7.2 Secure Deployment, Std 11–12 (p. 53): developers must not have access to production secrets or credentials; production secrets must be adequately protected."
+            ],
+        },
+        "7": {
+            guidance: "Private IP addresses or internal server names in responses reveal how the internal network is laid out.",
+            howToTest: [
+                "Check response headers (Via, X-Forwarded-For, X-Backend-Server, Location on redirects) for 10.x, 172.16–31.x, 192.168.x addresses or internal names.",
+                "Search page source and error pages for the same patterns.",
+                "Request the site by its IP address and with an HTTP/1.0 request without a Host header, then check any redirect target.",
+            ],
+            evidencePrompt: "The header or page and the internal address it revealed.",
+            terms: [{ term: "Private IP address", meaning: "Addresses such as 10.x.x.x, 172.16–31.x.x and 192.168.x.x that are only used inside a network." }],
+        },
+        // --- Privacy and Confidentiality ---------------------------------------------------
+        "8": {
+            guidance: "URLs are saved in browser history, server and proxy logs, and sent to other sites in the Referer header, so tokens and personal data must not appear in them.",
+            howToTest: [
+                "Log in and use the main features (search, profile, password reset, payments) while watching the address bar and the browser's developer tools Network tab.",
+                "Look for session IDs, tokens, passwords, national ID numbers, e-mail addresses or phone numbers in query strings.",
+                "Check password-reset and verification links: their tokens must be single-use and expire quickly.",
+            ],
+            evidencePrompt: "Example URL pattern and the sensitive parameter name (mask the values).",
+            terms: [{ term: "Query string", meaning: "The part of a URL after the \"?\", e.g. ?id=5&token=…" }],
+        },
+        "9": {
+            guidance: "Data stored in the browser (cookies, localStorage, IndexedDB) can be read by scripts on the page and by anyone using the same device.",
+            howToTest: [
+                "Log in, then open developer tools → Application (Chrome) or Storage (Firefox).",
+                "Inspect cookies, localStorage, sessionStorage and IndexedDB for passwords, personal data, tokens or other sensitive values stored unencrypted.",
+                "Log out and check whether the sensitive data is removed.",
+            ],
+            evidencePrompt: "Storage location, key name and the kind of data stored (mask the values).",
+        },
+        "10": {
+            guidance: "Web archives and search engines may keep copies of pages that exposed data before it was removed from the site.",
+            howToTest: [
+                "Search https://web.archive.org/web/*/your-domain/* for old pages, especially admin, export or document URLs.",
+                "Search with site:your-domain plus filetype:pdf, filetype:xls, filetype:sql or filetype:doc.",
+                "Request removal of anything sensitive from the archive and from search engines.",
+            ],
+            evidencePrompt: "Archived or indexed URLs found and what they contained.",
+        },
+        "11": {
+            guidance: "Every external script runs with full access to your pages; a compromised or untrusted third party can steal data or change content.",
+            howToTest: [
+                "In developer tools → Network, list every script, stylesheet, font and iframe loaded from other domains.",
+                "For each one, confirm it is needed and comes from a trusted provider.",
+                "Check that third-party scripts use Subresource Integrity (an integrity=\"sha384-…\" attribute) where possible and that nothing loads over plain http.",
+            ],
+            evidencePrompt: "List of external origins, and which lack integrity attributes.",
+            terms: [{ term: "Subresource Integrity (SRI)", meaning: "A hash in the script tag that makes the browser refuse the file if it was modified." }],
+        },
+        "12": {
+            guidance: "Pages with personal data must not be stored by browsers or shared proxies, or the next person using the computer may see them.",
+            howToTest: [
+                "Log in and open a page with personal data; in developer tools, read its Cache-Control response header.",
+                "It should be \"no-store\" (or at least \"private, no-cache\") on sensitive pages.",
+                "Log out and press the browser's Back button: sensitive pages must not reappear from the cache.",
+            ],
+            evidencePrompt: "Page checked, Cache-Control value, and result of the Back-button test.",
+        },
+        "13": {
+            guidance: "Passwords and personal data must only travel over encrypted HTTPS connections, including in e-mails the system sends.",
+            howToTest: [
+                "Check that every form (login, registration, contact, payment) submits to an https:// address.",
+                "In developer tools → Network, confirm the page's API calls use HTTPS.",
+                "Check that e-mails sent by the system do not contain passwords or sensitive data in plain text.",
+            ],
+            evidencePrompt: "Forms and endpoints checked, and any that used HTTP.",
+        },
+        "14": {
+            guidance: "Every page of a site that handles sensitive data must be served only over HTTPS.",
+            howToTest: [
+                "Open http://your-site/ and a few deep links with http:// instead of https://.",
+                "Each one must redirect (status 301 or 308) to the HTTPS version.",
+                "Repeat for the subdomains in use (www, portal, api…).",
+            ],
+            evidencePrompt: "URLs tested and the redirect status codes received.",
+        },
+        "15": {
+            guidance: "An HTTPS page that loads scripts, images or frames over plain HTTP can be tampered with on the network.",
+            howToTest: [
+                "Open the main pages over HTTPS with the developer tools Console open; browsers print \"Mixed Content\" warnings.",
+                "Search the page source for src=\"http:// and href=\"http:// on scripts, styles, iframes, images and form actions.",
+                "Repeat on pages behind the login.",
+            ],
+            evidencePrompt: "Pages and the resources they loaded over HTTP.",
+            terms: [{ term: "Mixed content", meaning: "An HTTPS page that loads some of its parts over unencrypted HTTP." }],
+        },
+        "16": {
+            guidance: "HSTS tells browsers to always use HTTPS for the site, which prevents attackers from downgrading connections to HTTP.",
+            howToTest: [
+                "In developer tools, check the Strict-Transport-Security header on HTTPS responses.",
+                "max-age should be at least 15768000 (six months); includeSubDomains is recommended.",
+                "Confirm it is sent on all pages, not only the home page.",
+            ],
+            evidencePrompt: "The header value and the pages checked.",
+            terms: [{ term: "HSTS", meaning: "A response header that makes browsers refuse plain-HTTP connections to the site." }],
+        },
+        "17": {
+            guidance: "Old protocol versions and weak ciphers allow encrypted traffic to be decrypted or tampered with.",
+            howToTest: [
+                "Run SSL Labs (https://www.ssllabs.com/ssltest/) for public sites, or testssl.sh for internal ones.",
+                "Confirm SSLv3, TLS 1.0 and TLS 1.1 are disabled, and no RC4, 3DES, NULL or EXPORT ciphers are offered.",
+                "Review any known vulnerabilities the tool lists (for example Heartbleed or ROBOT).",
+            ],
+            evidencePrompt: "Tool used, its grade or summary, and any weak protocol or cipher found.",
+            terms: [{ term: "Cipher suite", meaning: "The set of algorithms used to encrypt a TLS connection." }],
+        },
+        "18": {
+            guidance: "Browsers only trust certificates from recognised authorities that match the hostname and are in date. Anything else trains users to click through warnings.",
+            howToTest: [
+                "Click the padlock and view the certificate: issuer, validity dates and the names it covers.",
+                "Confirm it is issued by a trusted authority, unexpired, covers every hostname in use, and uses a 2048-bit (or larger) RSA key or an ECDSA key.",
+                "Confirm renewal is automated or tracked so it does not expire unnoticed.",
+            ],
+            evidencePrompt: "Issuer, expiry date, key type and size.",
+            references: [
+                "SWMS v1.0 §2.5 N: organizations should continuously ensure communication encryption certificate updates of their website.",
+            ],
+        },
+        "19": {
+            guidance: "Only standard, well-reviewed algorithms should be used. Custom or outdated ones (MD5, SHA-1, DES, RC4) can be broken.",
+            howToTest: [
+                "Ask the developers which algorithms are used for hashing, encryption and signing, and where.",
+                "Search the code for md5, sha1, des, rc4, blowfish, and home-made \"encrypt\" or \"obfuscate\" functions.",
+                "Confirm passwords are hashed with bcrypt, scrypt, Argon2 or PBKDF2.",
+            ],
+            evidencePrompt: "Algorithms found and where they are used.",
+            terms: [{ term: "Hash", meaning: "A one-way fingerprint of data. MD5 and SHA-1 are now considered broken." }],
+            references: [
+                "CMCSRS v2.0 §6.18 a: use secure cryptographic systems approved by INSA when applying cryptographic security measures.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls."
+            ],
+        },
+        "20": {
+            guidance: "Good algorithms fail when misused: fixed keys or IVs, ECB mode, keys stored in the code, or predictable random numbers.",
+            howToTest: [
+                "Review encryption code for hard-coded keys or IVs and for ECB mode.",
+                "Check tokens and passwords are generated with a cryptographically secure generator (Python secrets, Java SecureRandom, crypto.randomBytes), not random().",
+                "Check outgoing HTTPS connections never disable certificate verification.",
+                "Check where keys are stored: environment variables or a secret store, not the repository.",
+            ],
+            evidencePrompt: "Each problem found and its location.",
+            terms: [
+                { term: "IV (initialisation vector)", meaning: "A random value that must be different for every encryption." },
+                { term: "ECB mode", meaning: "An encryption mode that leaks patterns in the data; it should not be used." },
+            ],
+            references: [
+                "CMCSRS v2.0 §6.18 a: use secure cryptographic systems approved by INSA when applying cryptographic security measures.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls."
+            ],
+        },
+        // --- State Management ----------------------------------------------------------
+        "21": {
+            guidance: "Values the server trusts from the browser (hidden fields, cookies, prices, roles, step numbers) can be changed by the user.",
+            howToTest: [
+                "Use an intercepting proxy (OWASP ZAP or Burp Suite) or the browser developer tools to inspect hidden form fields, cookies and request parameters.",
+                "Change values such as price, quantity, role, user ID or isAdmin and submit the request.",
+                "The server must reject the change or recalculate the value itself.",
+            ],
+            evidencePrompt: "Parameter changed, value used, and the server's response.",
+            terms: [{ term: "Intercepting proxy", meaning: "A tool that lets you see and edit the requests between your browser and the server." }],
+            references: [
+                "SSDMS v1.0 §8.3.2.2 (ST2) Std 9, 11: manual penetration testing against the project's security test cases, including application-specific tests of business logic.",
+                "SSDMS v1.0 §6.2.2.1 (SR1) Std 3: the designer must review functionality from an attacker's perspective to understand how it could be misused.",
+            ],
+        },
+        "22": {
+            guidance: "Multi-step processes (applications, payments, approvals) must enforce the order of steps on the server, not only in the user interface.",
+            howToTest: [
+                "Walk through a multi-step process and note the URL or request of each step.",
+                "Try jumping straight to a later step, repeating a step (for example submitting a payment twice), or changing earlier data after approval.",
+                "The server must refuse out-of-order or repeated actions.",
+            ],
+            evidencePrompt: "Process tested, the step skipped or repeated, and the result.",
+            references: [
+                "SSDMS v1.0 §8.3.2.2 (ST2) Std 9, 11: manual penetration testing against the project's security test cases, including application-specific tests of business logic.",
+                "SSDMS v1.0 §6.2.2.1 (SR1) Std 3: the designer must review functionality from an attacker's perspective to understand how it could be misused.",
+            ],
+        },
+        // --- Authentication and Authorization Process -----------------------------------
+        "23": {
+            guidance: "Every protected page and API must check both that the user is logged in and that they are allowed to perform the action.",
+            howToTest: [
+                "Log in as a normal user and collect URLs of admin or other-role pages (from menus, JavaScript files or documentation).",
+                "Log out and request those URLs directly; then request them again as the normal user.",
+                "Repeat for API endpoints, including state-changing POST, PUT and DELETE requests.",
+                "Every request must end in a login redirect or a 401/403 response.",
+            ],
+            evidencePrompt: "URL, role used, and response status for each request.",
+            terms: [
+                { term: "Authentication", meaning: "Proving who you are (logging in)." },
+                { term: "Authorization", meaning: "Deciding what a logged-in user is allowed to do." },
+            ],
+            references: [
+                "CMCSRS v2.0 §5.7 e.6: each user should authenticate using an appropriate authentication method before being granted access to applications.",
+                "CMCSRS v2.0 §6.17 e: access control rules must align with business requirements, asset classification and legal obligations.",
+                "SWMS v1.0 §2.5 C–D: website access rights are granted and revoked via documented procedures; privileges are categorized by business requirements and website policy.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities."
+            ],
+        },
+        "24": {
+            guidance: "Login decisions made in the browser (password checks in JavaScript, hidden admin buttons) can be bypassed.",
+            howToTest: [
+                "Read the login page's JavaScript for password checks, hard-coded credentials or isLoggedIn flags.",
+                "Disable JavaScript, or edit local variables and storage (for example set role=admin in localStorage), then reload.",
+                "Confirm the server still refuses access to protected data and actions.",
+            ],
+            evidencePrompt: "What was changed and how the server responded.",
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        // --- Items with INSA references only (no authored test guidance yet; the review shows the registry note) ---
+        "25": {
+            references: [
+                "CMCSRS v2.0 §5.7 d.2: any default password for a user account should be changed to a strong, alternative password.",
+                "SWMS v1.0 §2.5 E: access credentials should be updated in a fixed time frame and whenever there is a change in structure or strategic mission.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities."
+            ],
+        },
+        "28": {
+            references: [
+                "CMCSRS v2.0 §5.7 e.2–3: special access privileges are restricted to a limited number of authorized individuals, documented and reviewed regularly (e.g. quarterly).",
+                "SWMS v1.0 §2.5 D: website access privileges should be categorized based on business requirements and the website policy.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities."
+            ],
+        },
+        "36": {
+            references: [
+                "CMCSRS v2.0 §5.7 e.1: all user account creation should be subject to a provisioning and approval process.",
+                "CMCSRS v2.0 §5.7 e.5: administrative accounts should require a password change regularly.",
+                "SSDMS v1.0 §7.2 Secure Deployment, Std 11–12 (p. 53): developers must not have access to production secrets or credentials; production secrets must be adequately protected."
+            ],
+        },
+        "37": {
+            references: [
+                "Related (IoT scope) CMCSRS v2.0 §6.31 f.5: enforce resource consumption limits and practice throttling.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities."
+            ],
+        },
+        "77": {
+            references: [
+                "Related CMCSRS v2.0 §6.28 c–e: event logs are produced and reviewed, protected against tampering and unauthorized access, and retained for at least one month.",
+                "SSDMS v1.0 §7.1 Secure Build, Std 12 (p. 50): the developer must implement security logging and monitoring."
+            ],
+        },
+        "90": {
+            references: [
+                "CMCSRS v2.0 §5.7 g.2, g.4: install software updates on time (e.g. within 30 days) and security patches in a timely manner (e.g. within 14 days).",
+                "CMCSRS v2.0 §6.25 c, e: run vulnerability management throughout the system life cycle, including assessments before deployment and after significant changes.",
+                "SWMS v1.0 §2.5 I, L, M: website changes and patches are reviewed, tested on a separate environment and approved under formal change control.",
+                "SSDMS v1.0 §9.2.2.1 (EM1) Std 5–7: identify applications and components that need patching (OS, application servers, libraries), test patches before production, and apply them in maintenance windows (critical fixes sooner).",
+                "SSDMS v1.0 §7.1 Secure Build, Std 7, 14, 21 (pp. 49–50): keep an allow-list of approved dependencies, verify them with SAST, and fail the build when they contain issues above a defined criticality."
+            ],
+        },
+        "91": {
+            references: [
+                "CMCSRS v2.0 §5.7 g.1, g.3: internet-connected software should be supported by its vendor; out-of-date (unsupported) software should be removed.",
+                "SSDMS v1.0 §9.2.2.1 (EM1) Std 10: teams must be able to determine the versions of all components in use, to tell whether they are affected by a vulnerability."
+            ],
+        },
+        "92": {
+            references: [
+                "CMCSRS v2.0 §5.7 c.6: insecure or unapproved services that are typically vulnerable to attack should be disabled unless a compensating control is implemented.",
+                "SSDMS v1.0 §9.2.2.1 (EM1) Std 1, 3: apply a secure configuration to every element of the technology stack and establish configuration standards for common stacks."
+            ],
+        },
+        "93": {
+            references: [
+                "CMCSRS v2.0 §5.7 d.1, d.3: unnecessary user accounts and unnecessary software, utilities and network services should be removed or disabled.",
+                "CMCSRS v2.0 §5.7 d.6: configure system components using industry-accepted standards and vendor hardening guides.",
+                "SSDMS v1.0 §9.2.2.1 (EM1) Std 1, 3: apply a secure configuration to every element of the technology stack and establish configuration standards for common stacks.",
+                "SSDMS v1.0 §7.2 Secure Deployment, Std 7–8 (p. 53): deployment tools are kept patched and their configuration hardened per vendor guidance."
+            ],
+        },
+        "94": {
+            references: [
+                "CMCSRS v2.0 §5.7 c.4: the default administrative password of any firewall or network security device must be changed to a strong password.",
+                "CMCSRS v2.0 §5.7 d.2: any default password for a user account should be changed to a strong, alternative password.",
+            ],
+        },
+        "95": {
+            references: [
+                "CMCSRS v2.0 §5.7 g.4: security patches should be installed in a timely manner (e.g. within 14 days of release).",
+                "SWMS v1.0 §2.5 O: follow and monitor periodic security updates and changes of the hosting service provider.",
+                "SSDMS v1.0 §9.2.2.1 (EM1) Std 5–7: identify applications and components that need patching (OS, application servers, libraries), test patches before production, and apply them in maintenance windows (critical fixes sooner)."
+            ],
+        },
+        "26": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "27": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "29": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "30": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "31": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "32": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "33": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "34": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "35": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "38": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "39": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "40": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "41": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "42": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "43": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "44": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "45": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "46": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "47": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "48": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "49": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "50": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "51": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "53": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "54": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "55": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "56": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "57": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "58": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 2: security tests must at least include testing for authentication, access control, input validation, encoding and escaping of data, and encryption controls.",
+            ],
+        },
+        "59": {
+            references: [
+                "SSDMS v1.0 §8.2.2.1 (RT1) Std 8: the tester must perform fuzzing, sending random or malformed data to the application.",
+            ],
+        },
+        "61": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "62": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "63": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "64": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "65": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "66": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "67": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "68": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "69": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "70": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "71": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "72": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "73": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "74": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "75": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "76": {
+            references: [
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "86": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "87": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "88": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "89": {
+            references: [
+                "SSDMS v1.0 §7.1 Secure Build, Std 13 (p. 49): the developer must validate all inputs.",
+                "SSDMS v1.0 §8.3.2.1 (ST1) Std 11: review high-risk modules (authentication, access control enforcement points, session management, external interfaces, input validators and data parsers) for common vulnerabilities.",
+            ],
+        },
+        "102": {
+            references: [
+                "SSDMS v1.0 §8.3.2.2 (ST2) Std 9, 11: manual penetration testing against the project's security test cases, including application-specific tests of business logic.",
+                "SSDMS v1.0 §6.2.2.1 (SR1) Std 3: the designer must review functionality from an attacker's perspective to understand how it could be misused.",
+            ],
+        },
+    },
+};
+//# sourceMappingURL=en.js.map