FedRAMP · CMMC · NIST SP 800-171

Federal control baselines never ask you to obfuscate. They ask what you shipped, and whether you looked at it.

These programmes assess a system against a catalogue of controls. Not one of those controls is satisfied by a transformation applied to browser code. What they do reach into is the pipeline around it: knowing what a release contains, scanning it for flaws and fixing them, controlling and recording changes, and accounting for where protected information travels. A protection step sits inside that pipeline, contributes to two parts of it, and silently defeats one of them if you put it in the wrong place.

See the Evidence Model Source Handling
The Short Version

Scan first · Record the build · Know where source goes

Three engineering decisions carry nearly all the assessable weight, and none of them is an option in the tool.

A clean scan can be a broken scanScanners read code. Protected code reads as nothing to report, not as an error.
Reconstructible beats rememberedHashes and a fixed seed turn "what did we ship" into a stored file.
The boundary question is about bytesIf source is in scope, use a path where the source body never leaves the machine.
Why This Page Exists

Two programmes, one recurring misunderstanding about client-side code

Teams selling software into United States federal agencies or into the defence supply chain arrive at a vendor page like this one with a specific hope: that a build setting will discharge an obligation. It will not, and pretending otherwise wastes the one thing an assessment is short of, which is time. FedRAMP governs the authorisation of cloud services for federal use and is assessed against the NIST SP 800-53 control baselines. CMMC is the Department of Defense mechanism for assessing how a contractor has implemented NIST SP 800-171 when controlled unclassified information is involved. Both operate at the level of a system and an organisation. Neither has an opinion about how readable your bundle is. What they do have is a set of expectations about the pipeline that produced it, and that is where this page is useful.

Controls attach to systems, not to files

An authorisation covers a service as operated, with its boundary, its inherited controls and its documented deviations. A file-level transformation has nowhere to attach in that model, which is why it appears in no baseline.

The pipeline is in scope even when the transform is not

How a release is assembled, scanned, recorded and shipped is squarely assessable. Your build is part of the system that produces the thing under authorisation, and it is judged accordingly.

One control family is actively harmed

Flaw identification depends on reading code. Ordering the pipeline so that reading happens after the step designed to prevent reading turns a working control into a silent one, and that is the failure worth preventing.

Scope

Establish which situation you are actually in

The same technical facts produce very different obligations depending on what you sell, to whom, and what kind of information ends up on your build machines. Engineers are frequently asked to satisfy a requirement without being told which of these applies, and the answers diverge immediately. Settle this first.

You operate a cloud service seeking federal authorisation

Then your browser code is part of the service under assessment. Inventory, scanning, change control and the records that evidence them are yours to produce, and the boundary of your system determines which external services you must account for. The protection step is an unremarkable part of your build once its ordering and its network behaviour are documented.

You are a contractor or supplier handling controlled information

Then the decisive question is whether your source itself carries that classification. If it does, every service that receives it becomes part of the conversation, and the source-local paths exist precisely so that answer can be no. If it does not, you are in the ordinary pipeline-hygiene case above.

You sell software that a federal customer will operate

Then your customer carries the authorisation and pushes requirements to you through contract terms: disclosure of components, remediation timelines, notification windows and evidence on request. Being able to describe your build precisely, and to produce a manifest for a specific release, is a commercial advantage before it is a compliance one.

Your code or data may be export controlled

Then the question is about where bytes travel and who can read them, not about how the program is written. It has the same engineering answer as the controlled-information case and a different legal one, so treat the determination as counsel's and the workflow choice as yours.

The Four Points of Contact

Where a JavaScript pipeline actually meets the baselines

Out of hundreds of controls, four families are influenced by how you build and ship browser code. Everything else — access control, identification and authentication, physical security, personnel screening, contingency planning, media protection — happens somewhere other than your bundler, and no toolchain performs any of it for you.

1. Knowing what is in a release

Component inventory is a baseline expectation, and for a browser application the honest inventory is derived from your dependency graph rather than from the shipped file. A lockfile-derived component list is produced before bundling and before protection, so the protection step cannot affect it. A list produced by pointing a scanner at a built artifact is a different thing entirely, and on a protected bundle it is worthless. Generate the inventory from the graph, attach it to the release, and the question is settled permanently.

2. Finding flaws and fixing them

This is the family that ordering breaks. Vulnerability scanning, software composition analysis, static analysis, secret scanning and licence review all identify things by reading names, strings, version markers and structure. Those are precisely the signals the transformations remove. A scanner pointed at a protected bundle finds nothing and reports success, which is indistinguishable from a genuinely clean result unless someone is looking carefully. The vulnerable dependency remains exactly as exploitable as it was. Run all of it in continuous integration, on plain source, before the protection step, and never on the shipped file.

3. Configuration and change control

Baselines expect you to know your configuration, to control changes to it, and to be able to show what changed and when. A protection step that produces different output every time it runs from unchanged input is an awkward thing to place in that model. A fixed seed removes the awkwardness by making the transformation a deterministic function of its input, and a build manifest that records a source hash and an output hash per file gives you a durable record tying a specific input to a specific shipped artifact.

4. Where information under your responsibility travels

Accounting for external service connections is standard, and a build-time service that receives your source is one. The distinction that matters is which workflow you run. The hosted API, the online tool, default npm protection and hosted desktop mode transmit the selected JavaScript. WinUI Local Standard, paid Local Advanced and the npm CLI with the local flag keep the source body on the build machine and delete the request file after each run, performing only a source-free entitlement and option check over the network. State that distinction rather than summarising it.

And the one that only looks like a contact point

Audit logging, incident reporting and awareness training come up constantly in these assessments and have no relationship to your bundle. The single thread worth following is that reporting clocks run from awareness, which makes detection engineering and readable production diagnostics a compliance concern rather than only an operational one.

A note on inherited controls

Much of what an assessment covers is inherited from a platform you did not build. That is normal and expected, and it is worth mapping deliberately, because time spent evidencing something your hosting provider already evidences is time not spent on the parts that are genuinely yours. Your build pipeline is one of the parts that is genuinely yours.

The Tension Worth Naming

Assessment wants to read the code, and protection exists to stop that

Omitting this section is what turns a compliance page into a brochure. A great deal of assurance work consists of somebody reading source: confirming what a component does, checking that a change stayed in scope, establishing during an incident exactly what was exposed, or verifying that a claimed control is implemented the way the plan says. Protection is designed to raise the cost of reading. Both things can be true at once, but only if you draw the boundary on purpose rather than discovering it midway through an assessment.

Everything that reads code runs first

Composition analysis, vulnerability scanning, static analysis, secret scanning and licence review belong in continuous integration against plain source. This single ordering rule prevents the most consequential mistake on this page.

Evidence is generated, not extracted

Do not plan to derive assurance artifacts from the shipped file. Produce the component list, the hashes and the manifest during the build, when the information is still present, and store them with the release.

Diagnostics are rehearsed before they are needed

Retain identifier maps privately for every release and walk one real production trace back to a file and line as an exercise. Reporting timelines start at awareness, and awareness is worth very little if nobody can act on it.

A Workable Order

The pipeline arrangement that resolves the tension mechanically

The sequence below removes the judgement call entirely. Everything that reads code runs early, against source. Everything that records, protects and ships runs late, against the artifact. Nothing has to be decided twice.

1
Determine whether your source is in scope

Controlled unclassified information, controlled technical data, or ordinary commercial code. This determination drives the workflow choice and belongs to your compliance function rather than to your build engineer.

2
Generate the component inventory from the dependency graph

Produced from lockfiles before bundling, so it is complete and unaffected by anything downstream. Attach it to the release rather than regenerating it later.

3
Run every code-reading control on plain source

Composition analysis, vulnerability scanning, static analysis, secret scanning and licence checks. If one of these ever runs against a protected file, the result is meaningless and looks like success.

4
Protect with a fixed seed, on a workflow matching your scope

Deterministic output makes the step reproducible for change control. If source is in scope, use a path that keeps the source body on the machine and record why.

5
Record hashes and retain the symbol maps

A source hash and an output hash per file, stored with the release, plus privately retained identifier maps so a production trace can be read later.

6
Re-run the end-to-end suite against the protected artifact

So anything a transform changed is caught in continuous integration rather than in production, where it becomes an incident with a reporting clock attached.

Honest Limits

What we will not claim

“Obfuscation satisfies a control”

There is no control in these baselines that a code transformation implements. It can be described accurately as a supporting measure in a system security plan, and describing it as more than that invites the scrutiny you were hoping to avoid.

“Our product is FedRAMP authorised”

Authorisations attach to systems as operated by organisations, not to development tools used inside them. What we provide is an accurate account of what each workflow does with your source, for your assessor to evaluate.

“This resolves your export control question”

Obfuscating a file does not change whether the underlying technical data is controlled, and it substitutes for no licence, exemption or authorisation. The useful contribution is a workflow where the source body never leaves your machine.

“We can tell you your obligations”

We can state precisely what a build pipeline does with your source, which is what this page does. Scope determinations, baseline selection, assessment readiness and reporting duties are decisions for your compliance function and your counsel on your own facts.

Frequently Asked

FedRAMP, CMMC and JavaScript, answered

Does FedRAMP or CMMC require JavaScript obfuscation?

No. Neither program names obfuscation, and no build option produces an authorisation or a certification. FedRAMP is an authorisation process for cloud services sold to United States federal agencies, assessed against NIST SP 800-53 control baselines. CMMC is the Department of Defense programme that assesses how a contractor implements NIST SP 800-171 when it handles controlled unclassified information. Both are about implementing and evidencing a set of controls across an entire system, and a transformation applied to browser code is not one of those controls.

Then why does a JavaScript build pipeline come up at all?

Because four control families reach into it, and one of them is damaged by the protection step if you order the pipeline wrongly. You have to know what is in a release and be able to say so, you have to scan for and remediate flaws, you have to control and record changes to a baseline, and you have to account for where information under your protection responsibility travels. A browser build touches every one of those, which is why the pipeline shows up in an assessment even though the transformation itself never does.

What is the single most common mistake teams make here?

Running vulnerability and composition scanning against the protected artifact instead of the source. Scanners work by reading code: they match library version strings, banner comments, identifier fingerprints and known code patterns. Name mangling and string transforms remove exactly those signals, so the scan comes back with nothing to report. That renders as a clean result rather than as an error, which means a genuinely vulnerable dependency stays exactly as exploitable while the dashboard turns green. Every control that works by reading code has to run before the protection step, on unprotected source.

Is our application source code controlled unclassified information?

Sometimes, and it is a determination your organisation has to make rather than one a vendor can make for you. Source written under a defence contract, source that embeds controlled technical data, and source that describes a controlled system can all fall in scope, while ordinary commercial application code usually does not. The question matters here because it decides whether sending that source to any external service is a transfer you need to account for, so settle it before choosing how you run the protection step rather than afterwards.

If our source is in scope, can we still use JavaScript Obfuscator?

Yes, using the paths that keep the source on the build machine. The hosted API, the online tool, default npm protection and hosted desktop mode all send the selected JavaScript to the configured endpoint. WinUI Local Standard, the paid Local Advanced tier and the npm CLI run with the local flag do not: the source body stays on the build machine and the request file is deleted after each run. A source-free entitlement and option check still goes over the network, the local executable is Windows-only, and a build that asks for VM bytecode protection fails with a clear message rather than quietly shipping weaker output. Those four facts are what an assessor will want stated precisely.

How does export control fit into this?

It follows the same structural answer, which is why it belongs on this page. Where source is controlled technical data, the concern is release to a foreign person or transfer outside an approved boundary, and that concern is about where the bytes go rather than about how the code is written. Obfuscating a file does not change its control status, and it is not a substitute for a licence, an exemption or an authorisation. The practical consequence is identical to the controlled-information case: use a workflow where the source body never leaves the machine, and have your export compliance function confirm the determination.

Does obfuscation count toward a system security plan?

It can appear as a supporting measure, described accurately, and it should never be presented as satisfying a control on its own. What it honestly provides is resistance to casual reading of shipped client code and a tamper-detection surface at runtime. What it does not provide is access control, encryption of data, boundary protection, identification and authentication, or any of the things the control families actually ask for. An assessor reading a plan that leans on obfuscation will read it as a gap rather than as a strength.

What should we do about change control and build records?

Make each release reconstructible and describable. A build manifest that records a source hash and an output hash for every file gives you a record that a specific input produced a specific shipped artifact, and a fixed seed makes the protection step a deterministic function of its input rather than a source of unexplained variation between builds. Together those turn the awkward assessment question, which is how you know what you shipped, into something you can answer with a stored file instead of a recollection.

How do we keep incident response workable on protected code?

By keeping the symbol maps and rehearsing the path back. Reporting timelines run from the moment you become aware of something, so the worst time to discover that nobody can read a production stack trace is during an incident. Generate and privately retain the identifier maps for every release, keep them keyed to the build they belong to, and walk a real trace back to a file and line once as an exercise. That single rehearsal is worth more than any amount of documentation about it.

Can you provide a FedRAMP authorisation or a CMMC certificate for our use of the tool?

No, and any vendor offering that is describing something other than how these programmes work. Authorisations attach to a system as operated by an organisation, and a certification assessment looks at the contractor being assessed. What we can give you is an accurate description of what each workflow does with your source, which is on this page and in the source-handling documentation, so that your assessor can evaluate it as one input among many.

Related Guides

Other compliance and evidence guides

The same evidence artifacts and the same source-handling facts answer questions across several frameworks. These pages cover the neighbouring ground:

Zero trust and client-side JavaScript · Cyber Essentials and the Essential Eight · Obfuscation, export control and the encryption question · Data residency and your source code · ISO 27001 and SOC 2 · SEC cyber disclosure and your front end · PCI DSS and JavaScript · SOX, GLBA and financial application JavaScript · HIPAA and JavaScript · GDPR and JavaScript · DORA and JavaScript · The Cyber Resilience Act · Security and trust · Security and source handling · Reproducible builds · Does obfuscation break your SBOM? · The European Accessibility Act and JavaScript · The EU AI Act and your front end · NIS2 and the JavaScript you ship

Next Step

Open your build configuration and check the order

Find where composition analysis and secret scanning run, and confirm they execute against source rather than against the protected output. Then check whether your release stores a component list and a per-file hash record. Those two checks take an afternoon, and between them they settle the question most likely to be answered wrongly in an assessment and the one most likely to be answered from memory.

See the Evidence Model › Reproducible Builds