# The macOS Security Compliance Project: NIST Baselines as Generated Configuration Profiles

> mSCP turns NIST SP 800-53, CIS and CMMC control text into configuration profiles, DDM assets and compliance scripts for macOS, iOS and visionOS. It is a build tool for compliance content, not an antivirus product.

**usnistgov/macos_security** — macOS Security Compliance Project

- Repository: https://github.com/usnistgov/macos_security
- Website: https://pages.nist.gov/macos_security
- Stars: 2,493 · Forks: 302
- Language: YAML
- License: NOASSERTION
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/usnistgov-macos-security

## What mSCP generates, and who the output is for

The macOS Security Compliance Project is a generator, not an agent. The README describes four outputs from one set of selected rules: configuration profiles to apply the rules, Declarative Device Management assets for management solutions that support declarative delivery, documentation explaining the setup, and compliance scripts to verify and enforce rules that profiles cannot. That split matters more than the feature list. A configuration profile is a plist an MDM pushes; a compliance script is something that has to run on the endpoint and report back. Rules that map to a managed preference become profiles. Rules that require inspecting a file, a kernel extension state or a running process end up in the script side, and those need an execution path your MDM may or may not provide.

The intended audience is spelled out in the repository metadata: system administrators, with the classifiers listing macOS and Linux as supported build platforms. The project is a joint effort of federal staff from NIST, NASA, DISA and Los Alamos National Laboratory, and the README states that mSCP is the technical implementation of NIST SP 800-219 (Rev. 2). Vendors are explicitly named as a second audience: the README says they can use mSCP as a source to build manifests, datapoints and other compliance content for their products. So there are two very different users here, the organisation enforcing a baseline and the company shipping compliance content inside another product.

## How a baseline becomes a profile: rules, baselines and the generation step

The repository layout shows the data flow plainly. There are top-level rules and baselines directories holding the YAML content, a schema directory holding the validation contract, and a custom directory for organisation-specific work. The Python package lives under src/mscp, and the entry point is mscp.py at the root, with the console script declared as mscp = "mscp.__main__:main" in pyproject.toml. The primary language of the repository is YAML, which tells you where the substance is: the rules are data, and the Python code renders that data into profiles and scripts.

The supported frameworks are listed in the README as NIST SP 800-53, NIST SP 800-171r3, NIST SP 800-171r2 (CMMC), CIS Benchmarks Level 1 and 2, CIS Controls v8, and CNSSI 1253. Coverage is not uniform across operating systems. NIST SP 800-53 and the 800-171 revisions cover macOS, iOS/iPadOS and visionOS; the CIS Benchmarks and CIS Controls rows list macOS and iOS/iPadOS only. If you are building a visionOS baseline, the CIS route is not available according to that table.

The dependency list in pyproject.toml is worth reading before you plan a build pipeline. It includes jinja2 for templating, pydantic and jsonschema for validation, ruamel.yaml alongside pyyaml, pandas and openpyxl for tabular output, lxml, and typst for document rendering. That is a heavier footprint than a shell script that writes a plist, and it means the build machine needs a full Python environment rather than a single binary.

## Installing mSCP and generating your first baseline

The package is published as mscp and requires Python 3.12 or newer, per the requires-python field in pyproject.toml. The project metadata also declares support for Python 3.13 and 3.14. The repository ships an install.md at its root, and the README points readers to the project website at pages.nist.gov/macos_security for the fuller guidance. The console script declared in pyproject.toml is the entry point, and the root mscp.py file is the module it calls into.

```toml
[project.scripts]
mscp = "mscp.__main__:main"
```

That block is copied from pyproject.toml. It tells you the command you get after installation is mscp, and that it resolves to mscp.__main__:main. The project requires Python 3.12 or newer, so check your interpreter before anything else.

```toml
[project]
name = "mscp"
dynamic = ["version"]
requires-python = ">=3.12"
```

Once installed, the workflow is to pick a baseline, optionally select a subset of rules, and generate output. The baselines directory holds the shipped baselines and the custom directory exists for organisation-specific ones. The README's framing is that you choose the security rules to enforce and mSCP generates everything you need, so the selection step comes before generation, not after. The generated artefacts are what you hand to your MDM: a profile to push, DDM assets where the management solution supports declarative delivery, and scripts for the rules profiles cannot express.

A practical first run on a test machine should be a small baseline rather than a full one. Generate, inspect the resulting profile in a plist editor, and confirm the payload keys match what your MDM accepts before you scope it to a fleet. The documentation output that mSCP produces alongside the profile is the piece to read at this stage, because it explains the setup for each rule. The install.md file is the project's own account of setup, and it is the file to follow rather than a reconstructed sequence.

## Where mSCP stops: no detection, no endpoint agent, no rollback story

The most common misunderstanding about a project named macOS Security Compliance is that it secures a Mac the way antivirus does. It does not. Nothing in the README describes malware detection, scanning, quarantine or real-time protection. mSCP produces configuration content and the scripts that check whether the configuration holds. If a user installs a malicious browser extension, mSCP has no opinion. If you need endpoint detection, this is the wrong tool and no amount of baseline tuning changes that.

The second boundary is enforcement. Profiles can set managed preferences, but a rule that needs to inspect a running process or a file's contents cannot be expressed as a preference. The README acknowledges this directly: compliance scripts exist to "verify and enforce rules that profiles cannot." Those scripts need somewhere to run. An MDM that only pushes profiles and never executes scripts will leave that portion of the baseline unenforced, and the generated documentation will still describe the rules as part of the baseline. That gap is a deployment problem, not a bug, but it is the one that bites.

Third, the repository does not document rollback. There is no described path for reverting a baseline once applied, and the README is silent on what happens when a profile is removed from a device that already had a compliance script run against it. Plan your change control around that silence. Also note the classifier in pyproject.toml: Development Status :: 4 - Beta. The project ships dated releases, with release_27.0 (mSCP 2.0, Release 27.0) dated 2026-09-11, but the packaging metadata still labels it beta.

## mSCP against a hand-written MDM profile or a commercial benchmark

The obvious alternative is writing your own configuration profile in your MDM's profile editor. The difference is provenance. A hand-written profile encodes one administrator's reading of a control. mSCP encodes a mapping from NIST SP 800-53 Revision 5 controls, and the README states the rules are derived from that publication. When an auditor asks which control a setting satisfies, the generated documentation is the answer, and it is regenerated when the baseline changes. A hand-written profile has no such trail unless you maintain it yourself.

The second alternative is a commercial compliance product that ships its own Apple benchmarks, typically a CIS-derived set wrapped in a scanning agent. Those products give you detection and reporting on the endpoint, which mSCP does not. What they do not give you is the source: mSCP's rules are YAML in a public repository under the usnistgov organisation, and an organisation can fork the baseline, add rules in the custom directory, and keep the whole thing in version control. The trade is operational convenience for inspectability. If your requirement is a dashboard showing fleet compliance percentages, a commercial scanner answers that question faster. If your requirement is defensible, versioned, editable control mappings, mSCP is the more direct route.

## Licence, upgrade cadence and the cost of tracking baselines

The repository's LICENSE.md is the licence file, and the README badge states CC BY 4.0. The pyproject.toml metadata agrees, declaring license = {text = "CC-BY-4.0"}. GitHub's licence detector reports NOASSERTION for this repository, so treat the badge and the packaging metadata as the project's own statement and read LICENSE.md before you redistribute generated content. Configuration profiles and scripts generated from the rules are derivative output of a CC BY 4.0 work; whether your distribution triggers attribution obligations is a question for your own counsel, not something the README settles.

Upgrade cost is real and recurring. Releases are dated and versioned by OS guidance: release_27.0 (mSCP 2.0, Release 27.0) on 2026-09-11, tahoe_rev3 (Tahoe Guidance Revision 3.0) on 2026-06-22, and visionos26_rev3 (visionOS 26 Guidance Revision 3.0) on 2026-06-22. Each Apple OS release brings a guidance revision, and each revision can move rules between the profile side and the script side. The last push to the repository was on 2026-09-24, so the project is being updated on a short cycle. Budget for a re-generation and a re-test pass per OS cycle, not a one-time setup.

There is a supply-chain detail worth noting. The [tool.uv] section of pyproject.toml documents a dependency cooldown: the resolver ignores releases published less than a week ago, mirroring a 7-day cooldown in .renovaterc.json5. That is a deliberate choice to avoid adopting a freshly published, possibly compromised dependency version. If your organisation pins dependencies through a different resolver, you lose that protection unless you replicate it.

## Conclusion

Adopt mSCP if you already run an MDM and need auditable, versioned Apple baselines derived from NIST SP 800-53, CIS or CMMC rather than hand-written profiles. Skip it if you want endpoint antivirus, a scanner or a pop-up security centre; mSCP generates compliance content and does not detect malware. Before committing, confirm that your MDM can consume the generated profile and DDM output, and check whether the rules you need are enforced by a profile or require the compliance scripts instead.

## FAQ

### Is the macOS Security Compliance Project an antivirus product?

No. The README describes mSCP as generating configuration profiles, DDM assets, documentation and compliance scripts from security rules derived from NIST SP 800-53 Revision 5. Nothing in the README mentions malware detection, scanning or quarantine.

### Which operating systems does mSCP support?

The README lists macOS, iOS/iPadOS and visionOS as supported platforms. Coverage differs by framework: NIST SP 800-53 and the 800-171 revisions cover all three, while the CIS Benchmarks and CIS Controls rows list macOS and iOS/iPadOS only.

### What Python version does mSCP need?

pyproject.toml sets requires-python to >=3.12 and declares classifiers for Python 3.12, 3.13 and 3.14. The package installs as mscp and exposes a console script named mscp.

## Sources

- [Issues](https://github.com/usnistgov/macos_security/issues)
- [Project website](https://pages.nist.gov/macos_security)
- [README](https://github.com/usnistgov/macos_security/blob/main/README.md)
- [Releases](https://github.com/usnistgov/macos_security/releases)
- [usnistgov/macos_security on GitHub](https://github.com/usnistgov/macos_security)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/usnistgov-macos-security