Questionnaire Guide

1. Before You Start

Answer from the point of view of the product, product line, division, or organisation you want the documents to cover. If the questionnaire is being completed by a non-technical person, involve someone who understands the codebase, dependency management, vulnerability handling, and release process.

Use the closest truthful answer. Do not overstate maturity. If a process is informal, incomplete, or only applies to some products, choose the answer that reflects that limitation.

Do not enter secrets. Avoid source code, passwords, API keys, private customer data, exploit details, unreleased vulnerability details, or confidential incident records. The generator is local-first, but the documents may later be shared with customers, auditors, or internal stakeholders.

2. New to Memory Safety

If this topic is new, start with Memory Safety 101 and the Memory Safety Glossary before completing the questionnaire.

Memory safety is a way of reducing a common class of software bugs. In simple terms, it asks whether software can accidentally read, write, or manage memory in a way that it should not.

These issues are most common in low-level languages such as C, C++, Assembly, Objective-C, and similar code. Risk is higher when that code handles network traffic, login, cryptography, firmware, drivers, media files, or content supplied by users.

You do not need to be a memory safety specialist to complete the questionnaire. If you are unsure, choose the closest truthful answer and, where possible, ask an engineering or security colleague for estimates such as language mix, security tooling, SBOM status, vulnerability disclosure process, and transition plans.

The generator helps turn those answers into structured planning and evidence documents. It does not prove compliance, certify security, or replace technical or legal review, but it gives you a practical starting point for the right internal conversations.

3. Company Information

Company name: Use the organisation or client name that should appear on the generated documents.

Roadmap scope: Choose organisation-wide only if the answers apply broadly. Use product line or division if the assessment is narrower.

Document classification: Choose how sensitive the generated output should be treated internally. This is a label in the generated documents; it is not an access control system.

Executive sponsor: Use the person accountable for the roadmap, budget, or security programme. If unknown, leave it blank rather than inventing a name.

4. Technology Landscape

Memory-unsafe languages: In this questionnaire, C, C++, Assembly, Objective-C, and similar low-level languages are treated as memory-unsafe because common mistakes can cause memory corruption vulnerabilities.

Memory-safe languages: Rust, Go, Java, C#, Swift, Python, JavaScript, TypeScript, and similar managed or safety-focused languages usually reduce direct memory corruption risk. Some packages may still call native code underneath.

Unsafe percentage: Estimate the percentage of the in-scope codebase written in memory-unsafe languages. If you do not know, ask engineering or use repository language statistics as a rough guide.

Deployment contexts: Select where the software runs. Network-facing, firmware, cryptographic, authentication, and user-content processing contexts usually increase risk because defects are more likely to be exploitable or high impact.

High-risk code areas: Select areas where memory safety mistakes could directly affect confidentiality, integrity, availability, safety, or customer trust.

5. Security Posture

SAST: Static application security testing. Tools that inspect source code or compiled artefacts for security defects.

DAST: Dynamic application security testing. Tools that test a running application from the outside.

SCA: Software composition analysis. Tools that identify third-party dependencies and known vulnerabilities.

Fuzzing: Automated testing that feeds many unexpected inputs into software to find crashes and security defects.

Sanitisers: Compiler or runtime checks such as AddressSanitizer or MemorySanitizer that help detect memory errors during testing.

Compiler hardening: Mitigations such as ASLR, stack canaries, control-flow integrity, and FORTIFY_SOURCE. These reduce exploitation risk but do not remove the underlying vulnerability class.

Vulnerability disclosure: Select the highest level that is genuinely in place. A public security contact is not the same as a formal vulnerability disclosure policy, bug bounty, or CNA capability.

CWE-1399 classification: Choose yes only if memory safety vulnerabilities are consistently classified using the memory safety CWE taxonomy or equivalent internal classification.

6. Memory-Safe Language Transition

Not yet considered: No practical evaluation or planning has started.

Evaluating options: The team is comparing languages, tooling, compatibility, or migration approaches.

Pilot project underway: A bounded proof of concept or production-adjacent trial exists.

Partial adoption: Some new or migrated production code is already written in memory-safe languages.

Advanced: Most new in-scope code is memory-safe, and remaining unsafe code is actively governed, isolated, or being reduced.

Preferred languages: Select languages under serious consideration. If the organisation has not made a decision, choose undecided rather than selecting a language for appearance.

7. Regulatory Context

Target markets: Select jurisdictions or customer groups where the in-scope product is sold, supplied, or planned. This affects the regulatory mapping in the generated documents.

EU market: Select this if the in-scope product with digital elements is placed, or planned to be placed, on the EU market. This does not mean the tool certifies CRA compliance.

US federal or critical infrastructure: Select these only if the product is supplied into those environments or the organisation reasonably expects those requirements to matter.

Secure by Design Pledge: Select signed only if the organisation has formally signed. Select considering if it is being evaluated but not yet signed.

8. Dependencies and SBOM

SBOM: A Software Bill of Materials is an inventory of software components and dependencies. CycloneDX and SPDX are common formats.

No SBOM: Choose this if there is no repeatable component inventory for the in-scope product.

Manual or partial: Choose this if component lists exist but are incomplete, manually maintained, or not tied to release artefacts.

Automated: Choose this if SBOMs are generated by build, release, dependency, or security tooling.

Automated with memory safety classification: Choose this only if dependencies are also classified by language or memory safety exposure, including native bindings where known.

SBOM upload: If you upload a CycloneDX or SPDX JSON file, it is parsed locally in your browser. The file is not uploaded to the server by the generator.

9. Transparency and Reporting

Transparency preference: Internal means documents are mainly for internal planning. Customers or partners means the organisation expects to share parts of the output externally. Public disclosure means the organisation expects to publish or summarise roadmap progress publicly.

Update frequency: Choose how often the organisation can realistically review progress and regenerate documents. Quarterly is useful for active programmes; annual may be more realistic for early-stage planning.

Timeline preference: Auto-calculate is safest for most users. Choose a fixed timeline only if leadership has already committed to that planning window.

10. Additional Notes

Use this field for constraints that affect the roadmap, such as legacy platform support, regulated release cycles, safety-critical certification dependencies, limited specialist hiring capacity, or planned architecture changes.

Keep notes factual and high level. Do not paste sensitive vulnerability details, customer names, contract terms, secrets, or source code.

11. Using an Authorised Assistant or Agent

You may use an authorised assistant, AI agent, or browser automation tool to help complete the questionnaire if your organisation permits it and the assistant has been given appropriate access by you.

The MSCD Generator itself processes questionnaire answers in your browser. However, if you provide answers, SBOM files, notes, screenshots, or generated outputs to an external assistant or AI service, that external service may process or store the information under its own privacy terms and security controls.

You remain responsible for checking every answer before generating documents. Do not give an assistant secrets, credentials, source code, exploit details, unreleased vulnerability information, customer data, or anything your organisation has not approved for that assistant to handle.

The current product has no public API. Authorised assistants must use the browser-based workflow unless a future Enterprise API is separately agreed with appropriate authentication, rate limits, and data-processing terms.

12. Review Guidance

Before generating documents, review the answers with engineering, security, and compliance stakeholders where possible. The output is only as accurate as the questionnaire responses.

The structured evidence aids include DOC-1 Memory Safety Roadmap, DOC-2 Posture Assessment, DOC-3 MSL Selection Rationale, DOC-4 Executive Summary, DOC-5 Risk Register, DOC-6 CRA Readiness Evidence Annex, baseline JSON, and local attestation JSON. They are not legal advice, certification, a conformity assessment, or a substitute for audit.

For the formal source basis behind the rules engine, see the Methodology and Compliance Disclaimer.