Files
macos_security/.github/ISSUE_TEMPLATE/framework-request.yaml
Dan Brodjieski 2c93e52ae8 Refactor enforcement models and update issue templates (#706)
* chore: update issue templates

* chore: update issue templates

* refactor: create EnforcementInfo class to support hierarchy

platforms with differing enforcement methods are now correctly captured and generated

* chore: re-add macOS 14 support for initial release

* refactor: split macsecurityrule into references, mobileconfig, and enforcement_info modules

Extracts reference submodels (NistReferences, DisaReferences, CisReferences,
bsiReferences, bzkReferences, hhsReferences, customReferences, References) into
references.py and mobileconfig model + XML rendering utilities into mobileconfig.py.
Consolidates duplicate _create_value_element/_create_static_value_element into a
single create_value_element function. Adds Google-style docstrings throughout and
widens ResultDef fields to accept "$ODV" on all three types.

* refactor: add runtime validation and fix schema issues

- Add @model_validator to ShellCheck, ShellFix, DefaultStateShell enforcing
  that either shell or additional_info (or note) must be provided, and that
  result is required when shell is present on ShellCheck
- Add OdvHint/OdvValidation models in odv.py and a @field_validator on
  Macsecurityrule.odv to catch missing hint fields (e.g. datatype) at runtime
- Wrap Macsecurityrule construction in load_rules with ValidationError handler
  so bad rules are logged and skipped rather than crashing the process
- Switch validate_rules to iter_errors so all failures per file are reported,
  not just the first; improve error output with field path and fix log message
  showing correct rules path; guard against missing id field with .get()
- Fix schema: move if/then/else out of properties in ddmDef, fix
  declarationtype typo in conditional, move additionalProperties out of
  properties on iOS and visionOS, add sfr to disa references, widen
  anyOf constraints on check/fix/default_state to require shell or
  additional_info, clean up redundant type+$ref on array entry,
  update resultDef boolean to not allow $ODV

* feat: add remove_mscp_apple_release and standardize --version flag

Add mscp admin remove subcommand that removes a platform version from
mscp_data.yaml, all rule YAML files, and the JSON schema — the inverse
of mscp admin update. Also renames --new_version to --version on the
update subcommand for consistency.

* refactor: fix version datatype in removal and add success string to validate

* chore: lint cleanup

* fix: re-added missing imports

* removed fix blob from 26 and 14

---------

Co-authored-by: Bob Gendler <robert.gendler@nist.gov>
2026-06-17 21:22:14 -04:00

62 lines
1.8 KiB
YAML

---
name: New Framework / Baseline Request
description: Ask for a new compliance framework or benchmark to be supported
title: '[Framework Request]: '
labels: ["area/baselines", "triage"]
body:
- type: markdown
attributes:
value: |
Use this template to request support for a compliance framework or benchmark that mSCP doesn't currently generate baselines for.
Before opening a new issue, please search the existing issues to make sure it isn't a duplicate.
- type: checkboxes
attributes:
label: Is there an existing issue for this?
options:
- label: I have searched the existing issues
required: true
- type: input
id: framework-name
attributes:
label: Framework / benchmark name
placeholder: e.g. ISO 27001
validations:
required: true
- type: input
id: issuing-org
attributes:
label: Issuing organization or authority
placeholder: e.g. a national standards body, regulator, or industry group
validations:
required: true
- type: input
id: reference-link
attributes:
label: Link to the published framework or benchmark document
placeholder: https://...
- type: dropdown
id: platforms
attributes:
label: Which platform(s) should this apply to?
multiple: true
options:
- macOS
- iOS/iPadOS
- visionOS
validations:
required: true
- type: textarea
id: why
attributes:
label: Why should mSCP support this framework?
description: Who needs it, and what gap does it fill that the existing supported frameworks don't?
validations:
required: true
- type: checkboxes
id: contribute
attributes:
label: Contribution
options:
- label: I am willing to help map this framework's requirements to existing or new rules