V1.0.0 RC

[cpholguera]

This PR applies the v1.0.0-rc remapping: every weakness gets a new, stable ID (and usually a new title), old IDs are consolidated or retired, and several brand new weaknesses are introduced. It also brings all weaknesses up to a single, consistent authoring standard (no placeholders left) and adds a few new metadata fields.

Check the CSV with the mappings from beta to v1.0.0 RC: maswe.csv

Result: 78 weaknesses (was 119), organized as:

Category	Count	ID range
MASVS-STORAGE	6	MASWE-0001–0006
MASVS-CRYPTO	11	MASWE-0007–0017
MASVS-AUTH	8	MASWE-0018–0025
MASVS-NETWORK	3	MASWE-0026–0028
MASVS-PLATFORM	12	MASWE-0029–0040
MASVS-CODE	10	MASWE-0041–0050
MASVS-RESILIENCE	15	MASWE-0051–0065
MASVS-PRIVACY	13	MASWE-0066–0078

There are no remaining placeholder or draft entries.

1. ID remapping

• 72 weaknesses renamed from their old ID/category to the new one (preserving lineage, e.g. old MASWE-0031 → new MASWE-0025).
• 47 absorbed weaknesses removed each was folded into a new weakness's content;
  their old ID is preserved in that file's mappings.maswe-beta list (see §4).
• 6 brand-new weaknesses created with no predecessor:
  • MASWE-0040 — Sensitive Data Leaked via Accessibility Services
  • MASWE-0048 — Malicious Code Included in the App
  • MASWE-0051 — Root/Jailbreak Detection Not Implemented
  • MASWE-0055 — Malware Detection Not Implemented
  • MASWE-0069 — Usage of Non-Privacy-Preserving Functionality
  • MASWE-0075 — Non-Reproducible Builds (classified under MASVS-PRIVACY-3 as a build-transparency weakness)
• IDs are consecutive and grouped by category: MASWE-0001–MASWE-0078 with no gaps, each MASVS
  category occupying one contiguous block in the canonical order STORAGE → CRYPTO → AUTH → NETWORK →
  PLATFORM → CODE → RESILIENCE → PRIVACY (see the table above). Within a block, weaknesses are ordered
  by their first mappings.masvs-v2 control, so all MASVS-STORAGE-1 weaknesses precede the
  MASVS-STORAGE-2 ones, and so on. Adding a weakness therefore means inserting it at its control's
  position, not appending the next free number. New MASWE IDs will not necessarily be consecutive in future releases, but they will always be unique and stable.

2. Content changes

• Every renamed file got its id/title updated to match the new scheme.

• Editorial merges: where multiple old weaknesses were consolidated into one, the new file's
  prose (Overview / Modes of Introduction / Mitigations) was rewritten to cover the union of the
  original content — not just the primary predecessor. Notable consolidations:

  • MASWE-0007 (Improper Encryption) — absorbs IV misuse, key reuse, and risky padding
  • MASWE-0018 (Lack of Authentication/Authorization on App Components) — absorbs services,
    broadcast receivers, content providers, activities, unauthenticated IPC, and more
  • MASWE-0019 (Lack of Auto-fill Support for Credential Providers) — absorbs passwordless auth,
    shared web credentials, and platform auth-API usage
  • MASWE-0047 (Using Non-Standard APIs for Security-Critical Functionality) — absorbs risky
    crypto, non-proven networking APIs, and non-standard auth; broadened to also cover apps that
    fail to leverage secure platform functionality (e.g. custom DNS vs. Private DNS)
  • MASWE-0050 (Unsafe Handling of Untrusted Data) — absorbs the entire "unsafe handling of data
    from X" family (network, backups, external interfaces, local storage, UI, IPC) plus SQLi,
    parsing/escaping, and deserialization
  • MASWE-0061 (Debug Artifacts Not Removed) — absorbs non-production resources, debugging
    symbols, and code that disables security controls; clarified against MASWE-0004 (which
    covers leaked leftovers vs. 0061's debug/resilience artifacts)
  • MASWE-0056 (App Attestation Not Implemented) — repositioned from "Official Store
    Verification" to app-signature/attestation-based integrity checking
  • Several others (0009, 0013, 0020, 0026, 0032, 0035, 0051, 0053, 0063, 0078,
    etc.) — smaller merges, see individual files' mappings.maswe-beta

• Placeholder finalization: every previously status: placeholder weakness (54 of them) has
  been fully written and promoted to status: new, and the temporary draft metadata block
  (draft.description / draft.topics) has been removed. Drafting drew on the related MASTG-TEST
  and MASTG-BEST content to keep the Modes of Introduction and Mitigations grounded in what is
  actually testable and actionable.

• Full standardization: every weakness now follows the authoring standard defined in
  .github/instructions/maswe.instructions.md:

  • The four required sections in a fixed order — ## Overview, ## Modes of Introduction,
    ## Impact, ## Mitigations (previously some pages ordered Impact before Modes of
    Introduction).
  • ## Overview opens with a single-sentence definition in the form " occurs when …".
  • ## Modes of Introduction describes only developer-introduced, testable causes (consequences
    were moved out to ## Impact); each bullet uses a bold short label.
  • ## Mitigations are actionable, imperative bullets with bold short labels.

• New threat and attack model: what an attacker achieves, and how, is no longer written as prose
  in each weakness. It is expressed as structured, ID-referenced frontmatter drawn from two new
  enumerations under .github/instructions/:

  • threats.yaml: the closed set of MAS-THREAT-XXXX outcomes (e.g. MAS-THREAT-0005:
    "Attackers can access sensitive data written to logs."), referenced by the new threat: field.
    78 threats, one per weakness.
  • attacks.yaml: the closed set of MAS-ATTACK-XXXX paths through which a threat is realized
    (e.g. MAS-ATTACK-0001: "Obtaining the app package and reverse engineering it."), referenced
    by the new attacks: [MAS-ATTACK-XXXX, ...] field, IDs in ascending order. 90 attacks, reused
    across weaknesses — an average of two per weakness, and every one of the 90 is used at least
    once.

  attacks.yaml is append-only: IDs are never reused or renumbered, so they are stable identifiers
  that MASTG content and external consumers can reference directly. threats.yaml instead holds a
  strict 1:1 correspondence with the weaknesses — MASWE-XXXX always pairs with MAS-THREAT-XXXX —
  so a threat ID moves whenever its weakness ID does.

• Standardized Impact model: with the outcome and attack paths moved to frontmatter, ## Impact
  now contains only the consequences — a flat bulleted list, each opening with a canonical label
  from the new .github/instructions/impact.yaml (Compromise of Sensitive Data, Authentication
  or Authorization Bypass, Bypass of Protection Mechanisms, Execution of Unauthorized Code,
  Financial Loss, Compromise of System Integrity and Business Operations, Violation of User
  Privacy, Loss of User Trust, Legal and Regulatory Non-Compliance) and closing with a
  resulting in clause. Unlike threats and attacks, impact labels are a fixed vocabulary and carry
  no IDs. Equivalent consequences share identical wording across weaknesses.

• Cross-references between related weaknesses added/fixed using the @MASWE-XXXX convention (e.g.
  MASWE-0047 ↔ MASWE-0069 now note their intentional security/privacy overlap).

3. Frontmatter/metadata changes

• requirement: added to all 78 weaknesses — a single normative sentence (e.g. "The app
  excludes sensitive data from application logs.") suitable for use as a testable requirement
  statement, positioned right after alias. Now documented as a required field in the authoring
  instructions.
• threat / attacks (new fields): added to all 78 weaknesses, positioned right after
  profiles. threat is a single MAS-THREAT-XXXX ID naming the outcome attackers achieve;
  attacks is a list of MAS-ATTACK-XXXX IDs (ascending order) naming the paths to it. Both
  reference the new threats.yaml / attacks.yaml vocabularies described in §2. Documented as
  required fields in the authoring instructions.
• mappings.maswe-beta: records which old (pre-1.0.0-rc, "beta") MASWE IDs are covered by this
  weakness, for traceability. This started as a top-level beta-coverage field and was later moved
  into mappings and renamed to maswe-beta for consistency with the other mapping fields.
• mappings.masvs-v2 audit: after the mechanical rename, every masvs-v2 control list was
  checked against the actual control definitions (../masvs/controls/*.md) and against a
  never-lose-a-mapping audit of all 119 predecessor files:
  • Controls genuinely inherited from absorbed weaknesses were unioned in (e.g. MASWE-0018 gained
    CWE-287 back after review).
  • Controls that no longer fit the re-scoped weakness were pruned (e.g. MASWE-0026 dropped
    MASVS-AUTH-1, MASWE-0050 dropped MASVS-PLATFORM-1/-3) — see commit 93f0d95 for the
    full rationale per file.
  • Confirmed all 24 MASVS-v2 controls are covered by at least one weakness.
• mappings.android-risks: reviewed all existing links against
  https://developer.android.com/privacy-and-security/risks and added the risk to 12 weaknesses that were
  missing it. All 44 risks on that page are now mapped to at least one MASWE; a few required
  judgment calls that were subsequently refined (e.g. bad-dns → MASWE-0047, broadened to also
  cover under-use of platform-provided secure functionality; unsafe-download-manager →
  MASWE-0044; use-of-native-code → MASWE-0045 and MASWE-0050). The values were also
  simplified from full URLs to the short risk identifiers (e.g. log-info-disclosure instead of
  https://developer.android.com/privacy-and-security/risks/log-info-disclosure), which the site
  renders from.
• mappings.android-core-app-quality (new field): added to 25 Android-relevant weaknesses,
  linking each to the matching item(s) in the
  Android Core App Quality checklist.
  Values use the current named IDs (e.g. Network_Security_Traffic, Minimize_Permissions,
  Cryptographic_Algorithms), and the two pre-existing legacy-style mappings (SC-* / PS-*
  numbering) were migrated to the named IDs. Every checklist item in the "Privacy and security"
  section is now covered by at least one weakness. The field is documented in the authoring
  instructions and is only used when platform includes android.

4. Traceability

Every new weakness's mappings.maswe-beta field lists the old MASWE ID(s) it supersedes or
absorbs, so old-ID → new-ID mapping (and content lineage for merged weaknesses) is fully
recoverable from the files themselves, independent of git history.

Verification performed

• All 78 id: fields match their filename; no duplicate IDs, and the IDs are consecutive
  (MASWE-0001–MASWE-0078) with every file sitting in the folder of its first masvs-v2 control.
• All frontmatter parses as valid YAML.
• All 78 weaknesses are new; no placeholder/draft entries and no leftover draft:
  metadata blocks.
• Every weakness has the four required sections in the required order, and each ## Overview opens
  with an "… occurs when …" definition.
• Every weakness's threat: resolves to an entry in threats.yaml and carries the same number as
  the weakness itself; every attacks: ID resolves to an entry in attacks.yaml; every ## Impact
  consequence uses a label from the canonical impact.yaml set.
• No stale status: deprecated / covered_by / deprecation_note metadata left behind.
• Zero unpreserved cwe/masvs-v1/masvs-v2 mappings across all 119 predecessor files (full
  audit script run against git history).
• All 24 MASVS-v2 controls, all 44 documented Android risks, and every "Privacy and security"
  Android Core App Quality checklist item are covered by at least one MASWE.

[TheDauntless]

🥳