Teams should scan all three surfaces because unsafe deserialization can hide in application code, serialized build artifacts, and test fixtures. The right approach is layered detection: review source for risky APIs, inspect .ser and .pkl files before deploy, and run harmless malicious-input tests in CI so the pipeline proves it rejects unsafe payloads.
Why Deserialization Checks Need to Cover Code, Artifacts, and Tests
Deserialization weaknesses are easy to miss because they do not live in one place. Risk is created when developers only review application code and forget that serialized objects can also arrive through build outputs, cached assets, fixtures, or test data. For teams that ship frequently, this becomes a supply-chain and release-integrity problem as much as a code-review problem, because the vulnerable input may enter after source review has finished. The NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames secure development and system integrity as control objectives, not as one-off code hygiene.
In practice, many teams discover unsafe deserialization only after a release has already absorbed a tainted fixture, generated artifact, or library-bound payload pattern.
How Teams Should Apply Layered Deserialization Review
The practical shift is to treat deserialization as a multi-surface assurance problem. Source code review should identify risky APIs and custom deserializers, but that is only the first layer. Build artifacts matter because some systems persist objects, caches, or metadata in serialized form and then rehydrate them later without the original source path being visible. Test assets matter because fixtures often mirror production data shapes closely enough to exercise dangerous code paths, and a test harness can quietly normalise unsafe parsing if it never sees hostile input.
A useful operating model is to align checks to where deserialization actually occurs rather than where teams prefer to look. That means:
- reviewing source for deserialization entry points, wrapper libraries, and unsafe defaults;
- inspecting binary or serialized files that are produced during build and release flows;
- validating that CI includes harmless negative tests that confirm unsafe payloads are rejected;
- confirming that deserialization failures are visible in logs or test output rather than being swallowed.
This also helps separate real coverage from assumed coverage. A source scanner can report clean results even while a packaged artifact still contains a risky object stream, and a test suite can pass while never exercising malformed input at all. Where teams rely on generated assets, the review should extend to the pipeline stage that creates them, because the control point may be build-time rather than commit-time. The NIST SP 800-63 Digital Identity Guidelines are not about deserialization directly, but they are relevant where serialized state carries identity assertions or session-related trust decisions that must not be silently replayed or altered.
This guidance breaks down when teams cannot inventory where serialized objects are created, stored, or reloaded across the delivery chain.
Where Deserialization Checks Usually Fail First
Tighter deserialization control increases review overhead, so teams have to balance coverage against the cost of examining non-obvious artifacts and fixture data. The trade-off is worthwhile because the easiest failure mode is incomplete scope: code gets checked, but the deserialized payload is embedded elsewhere.
Two edge cases matter most. First, some projects use multiple languages or libraries, so the risky format may differ by subsystem and the scanner needs format-aware rules rather than one generic regex. Second, test data can be treated as harmless even when it is structurally capable of exercising the same parser paths as production data. There is no consensus that source-only scanning is enough; for systems that serialise state across stages, it is not. Teams should also be careful not to confuse safe data serialization with safe object deserialization, because the former can still carry unsafe behaviour if object construction is reintroduced during load.
For operational teams, the key question is not whether deserialization exists somewhere in the codebase, but whether the organisation can prove every place that accepts or rehydrates serialized input is covered before release. That is the point at which review scope, pipeline gates, and artifact inspection need to converge.
Risk and Threat Considerations
Unsafe deserialization is a recognised execution-risk pattern because crafted payloads can trigger unexpected object construction, code paths, or trust decisions. The exposure increases when the same format is reused across source, generated files, and tests, since a weakness can persist even after code review appears complete.
Failure mechanism: An attacker or contaminated input source supplies a serialized object that reaches a parser, loader, or test harness with unsafe behavior enabled, allowing gadget-chain execution, logic corruption, or trusted-state manipulation.
Impact: The result can be remote code execution, integrity loss in build or test pipelines, compromised release artifacts, or false confidence that unsafe inputs are being rejected.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | 16 — Application Software Security | Deserialization review is a secure software control problem. |
| 8 — Audit Log Management | CI tests need visibility when unsafe payloads are rejected or mishandled. | |
| Recommendation — Scan code and build outputs for unsafe deserialization paths before release. Log deserialization failures so pipeline checks prove rejection of unsafe input. | ||
| NIST CSF 2.0 | PR.DS — Data Security | Serialized artifacts and fixtures are data-handling exposure points. |
| DE.CM — Continuous Monitoring | Layered checks require ongoing monitoring across code, artifacts, and tests. | |
| Recommendation — Protect serialized data across the delivery chain and validate trust boundaries. Continuously monitor build and test surfaces for unexpected serialized content. | ||
| MITRE ATT&CK | T1505 — Server Software Component | Unsafe deserialization can enable malicious code execution through application components. |
| Recommendation — Hunt for exploitation paths that abuse application components during loading. | ||
Practitioner Guidance
What to prioritise: Start with every place the system rehydrates state, not just the source file that imports a serializer. The highest-value checks are the ones that cover the widest release path, especially if artifacts are promoted between build, test, and production without being re-examined.
What to verify: Teams should verify that negative tests are actually exercising parser boundaries, that serialized files are inventoried before deployment, and that scanners understand the file types in use. If a control only sees source code, it is incomplete for this topic.
Practitioner takeaway: Deserialization review is only reliable when it follows the payload through the pipeline, because the dangerous object is often introduced or persisted outside the source file that developers first inspect.
Related resources from NHI Mgmt Group
- Why do source-code leaks from build pipelines matter to IAM and NHI teams?
- What breaks when security teams review source code but ignore compiled artifacts in agent workflows?
- How should security teams protect source code repositories from identity abuse?
- How should security teams govern developer agents that can act across code, build, and deployment systems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 9, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
