eMASS integration software
Judge an eMASS integration on the second submission. One-way export works once; what matters is whether POA&M items upsert on their eMASS external identifier, whether import brings an authorized system forward, and whether imported data stays labeled as imported.
Feeding eMASS by hand is one of the more reliably disliked jobs in DoD security work. It is repetitive, error-prone, and it produces nothing except getting data that already exists somewhere into a place it now also exists.
So “eMASS integration” gets claimed widely. The claims cover a wide range of things, and the range matters.
What the claim can mean
A CSV export. The product emits a file shaped for eMASS bulk upload. Somebody downloads it and uploads it. This is useful and it is roughly where most products stop.
A one-way API push. The product writes to eMASS directly. Better, and it fails in one specific way covered below.
A round trip. Data moves both directions. The product can pull the current state out of eMASS and push updates back. This is the one that matters for an already-authorized system, and it is rarer.
Ask which one you are being sold, and ask specifically about the second submission.
Why the second submission is the test
The first push works in every implementation. Data goes across, items appear, everyone is pleased.
The second push is where a design flaw becomes visible: POA&M items must upsert on the external identifier eMASS assigned them.
Without that, the second export creates a duplicate of every item, beside the ones your reviewer already has open. Your POA&M doubles. The reviewer’s view of your program becomes a deduplication exercise, and the credibility cost is out of all proportion to the size of the bug.
It is a small technical detail with a large practical consequence, and it is worth asking about explicitly because it is invisible in a demo that only pushes once.
What should move, in each direction
Outbound, to eMASS:
- Control information — implementation state per control
- CCI test results — per-CCI assessment outcomes, which is the granularity DoD assessment actually operates at
- POA&M items — upserted on the external identifier
- Inventory — the current asset picture
Inbound, from eMASS:
- The control baseline, so an already-authorized system can be brought forward rather than rebuilt from nothing
- POA&M items, including their external identifiers so the round trip is closed from the start
- Inheritance relationships recorded upstream, which matter enormously and are easy to lose
The inbound direction is what makes an integration useful to a program that already has an ATO — which is most programs. A tool that can only push assumes you are starting from zero, and almost nobody is.
Import should not write silently
The most important property of the inbound path is that it does not quietly overwrite your record.
Import should arrive as a reviewable session: here is what was found, here is what it would change, accept or reject. Silent writes from an external system into an authorization record are how records become untrustworthy — six months later nobody can tell which facts a person established and which appeared from an import.
Two related rules that matter in practice:
Imported data stays labeled as imported. A control marked inherited in eMASS should not become, after import, an ordinary locally-implemented control indistinguishable from one your team wrote. The provenance is part of the fact.
A stale proposal is refused, not applied. If the target changed between the import being prepared and someone accepting it, refuse. Somebody made a more recent decision and it should win over a queued import.
The transport details worth asking about
Mutual TLS. eMASS API access uses client certificate authentication. Ask where the client certificate lives. It should be an environment secret, not a value in a configuration file, and certainly not in the same repository as the application.
Least privilege. The integration should hold only the API scope it needs.
Auditing. Every push and pull should produce an audit event with a timestamp, the user, the action, the target and the result. When somebody asks in eight months why a POA&M item changed on a Tuesday, that is the record that answers.
Failure behavior. A partial push is worse than a failed one. Ask what happens when the third of four exports fails, and whether you can tell afterwards what made it across.
The submission bundle
Not every submission goes over the API. Sometimes what is needed is a package — one archive carrying inventory, control information, CCI test results and POA&M exports.
The detail that makes such a bundle trustworthy is a checksum manifest: SHA-256 per file, so the receiving end can verify it got what you sent rather than assuming. It costs almost nothing to produce and it converts “the file was probably fine” into something checkable.
What integration does not fix
An integration moves data. It does not improve data.
If your control information is incomplete, your CCI results are stale and your POA&M contains items nobody intends to remediate, an integration transmits all of that to eMASS faster and more reliably than a person would. The reviewer’s experience gets worse, not better, because the problems now arrive in volume and on schedule.
Get the record right first. The integration is the last mile, and it is only worth automating a journey whose destination is correct.