Mission Assurance Security Standard for Software

Palantir Technologies operates software and AI operations across the most sensitive environments in the world: classified government networks, active combat theaters, air-gapped intelligence systems, and critical commercial infrastructure. Over 20+ years, we have designed our deployment infrastructure and security posture to support these environments on an ongoing basis, with readiness for all new developments and technological advancements, such as the most recent advent of cyber-tuned LLMs.

This document proposes a candidate Mission Assurance Security Standard (MA-S2) framework for software, one to which we are actively working towards. Beyond meeting established frameworks (e.g, SOC 2, FedRAMP, IL5 / IL6, NIST SP 800-53, ISO 27001, etc.), the proliferation of AI-assisted vulnerability discovery has underscored the need for a heightened standard across the software landscape. MA-S2 is a proposed framework that outlines the security controls, identification and remediation capabilities, orchestration capabilities, and other attestation requirements for software.

We are publishing this proposed standard publicly and for comment because we view it as our responsibility to any enterprise that wishes to secure its own digital footprint and ecosystem, and we view it as our contribution to the broader security community. For any CISO, CFO, procurement officer, and security architect that believes its mission is as critical as those that are responsible for the United States’ national security, and wish to protect their environments to this same standard, we encourage them to urgently prioritize meeting these standards.

For the broader security community, we actively invite reviews and further contributions to ensure a collectively high and growing standard.

The Office of the CISO and the cybersecurity industry has operated for decades under a stable assumption: that finding vulnerabilities in complex software systems was the single most difficult and important challenge. Individual software solutions with large teams and programs (e.g., penetration testing cycles, bug bounties, etc.) have been faced with addressing the expensive, slow, and challenging process of vulnerability discovery.

The discovery of zero-day vulnerabilities in major operating systems and browsers, which previously required elite research teams, has become an automated, high-volume capability available to any sufficiently resourced adversary. The actors who are already exploiting this shift at a national level are already deploying these capabilities.

AI models are now capable of rapidly surfacing novel vulnerabilities in complex, multi-stage cyber attack paths. Organizations can identify more vulnerabilities and at a faster pace, but lack domain awareness and automated remediation infrastructure. It is no longer acceptable to be unable to answer the most basic questions of what software is running, where, and on what version. Industry must be able to respond at velocity and scale.

The Mission Assurance Security Standard (MA-S2) is organized around four key controls that represent the minimum viable posture for any software vendor operating in a modern, secure environment:

MA-S2 is intended for use by third parties, including customers, procurement organizations, regulators, and independent assessors, to evaluate the security posture of software vendors operating in their environments. A vendor’s adherence to MA-S2 is established through an independent assessment of evidence against each control domain, producing an MA-S2 attestation report that the vendor may share with customers and prospects under appropriate confidentiality terms.

Organizations may also use MA-S2 internally as a self-assessment framework to evaluate their own software posture and identify gaps.

Vendors must demonstrate the capability to continuously scan all software components they ship or operate for known and novel vulnerabilities, regardless of packaging format or deployment model, using tooling that integrates AI-assisted analysis alongside deterministic scanning methods. Point-in-time scanning is insufficient.

Control Domain 0 requires vendors to maintain a continuous, living record of their vulnerability landscape across the entirety of the software footprint.

When a Critical or High severity vulnerability with a known exploit is identified in a deployed release, the vendor’s platform must satisfy three requirements:

Vendors must establish, publish, and demonstrate adherence to remediation SLAs for identified vulnerabilities. SLAs must satisfy two requirements:

A vendor fails this control domain if they cannot demonstrate:

Vendors must demonstrate that their security posture accounts for the use of AI by adversaries to traverse multi-stage attack paths through software systems. This includes the ability to model how AI-assisted adversaries would sequence vulnerabilities across their software stack and to prioritize remediation based on exploitability in those respective contexts.

Control Domain 1 requires vendors to model and handle their exposure at the attack path level across the entire landscape of components, micro-services, and other elements of their architecture, such that chained findings that together constitute a certain severity are appropriately handled despite how individual findings may be handled in isolation.

A vendor fails this control domain if they cannot demonstrate:

Vendors must maintain a complete, real-time, machine-readable inventory of all software components across every environment in which their software operates. This inventory must include version, runtime configuration, and deployment location. It must be continuously updated, not generated on demand. Finally, it must be comprehensive across heterogeneous and all environments.

Control Domain 2 requires vendors to a maintain real-time and fully comprehensive inventory of their entire software supply chain, including first-party and inherited open-source code and all upstream systems / tooling upon which additional code is written.

A vendor fails this control domain if they cannot demonstrate:

Vendors must demonstrate the capability to autonomously orchestrate remediation actions across their full deployment fleet. This includes the deployment of patched releases, rollback of vulnerable releases, environment-specific suppression of findings, and more. Human authorization and / or involvement may be prompted or even required for specific classes of actions, but it must not be the bottleneck.

Control Domain 3 requires vendors to close the vulnerable code chain across every environment where it is deployed on an ongoing basis with autonomous remediation orchestration.

Where developer teams responsible for producing patched code and operator teams responsible for deployment authorization are organizationally distinct, the vendor must demonstrate a workflow that produces measurable, timestamped records for three milestones, outlined below. These milestones must be captured in a system of record (such as a ticketing system, workflow platform, or release management tool) and must be reportable on demand. Informal communications (chat, email, code review discussion) are not in scope of this control.

A vendor fails this control domain if they cannot demonstrate:

The current landscape of adversarial threats is extreme, and the advent of cyber-tuned LLMs is skyrocketing the rate of vulnerability identification. With hundreds of vendors rushing in to be the harness for specific models, CISOs must grapple with new bottlenecks: the need to create real-time visibility into exactly what versions of software are running across every type of environment, the ability to achieve rapid remediation with exact precision, and having the capacity to reliably close the remediation chain through autonomous orchestration.

We invite any organization that shares this assessment of the threat environment to contribute to MA-S2 as a standard for the software landscape, and as a vendor requirement for organizations’ software supply chains.

Any organization incorporating MA-S2 requirements into internal assessments of their own IT exposure and current software landscape, and any organization looking to evaluate their software vendors against this standard, should at minimum require sufficient evidence of answers to the following questions.