NIST SP 800-53 describes a number of controls that are directly supported by the architecture and implementation of this system.

The security posture of an XSLT system must be understood, like all systems, in its operational context.

Any system can be used insecurely. But some systems are easier to use securely than others.

In other words, how you use it makes all the difference, while at the same time, some simple principles and precautions applied at a deeper level - in the system's design and deployment - can also make a huge difference, by protecting you and your data by default, and by architectural and design features that "build in" data safety (and broader system security), not just excluding them as "not a problem" (which inevitably means someone else's problem).

The following synopsis lists SP 800-53 controls supported, broadly, by these applications, in their design, development and maintenance. Some of the ways these controls are addressed are consequences not of XSLT Blender as such, but of the open technologies (XML and XSLT) on which it is based.

AC-4 Information Flow Enforcement

The most important consideration for this assessment is how, in contrast to other web-based applications (which tend to do poorly in view of this control), XSLT Blender supports respecting boundaries around information flow simply by processing all data in the client application (browser), i.e. in software already within the user's perimeter. No data is exfiltrated or exposed to any process on another system.

Architecturally, this is accomplished by passing the capability (represented by the application) into the user's organization rather than bringing data out of it (albeit 'temporarily').

One security concern in the current environment is that these two scenarios - processing data in the browser, vs uploading it to a server and trusting its black box behaviors, are difficult to distinguish. Work needs to be done on exposing this difference and its significance to end users who must be responsible for this control.

AC-4 (14) Security or Privacy Policy Filter Constraints

When transferring information between different security domains, implement [Assignment: organization-defined security or privacy policy filters] requiring fully enumerated formats that restrict data structure and content. Discussion: Data structure and content restrictions reduce the range of potential malicious or unsanctioned content in cross-domain transactions. Security or privacy policy filters that restrict data structures include restricting file sizes and field lengths. Data content policy filters include encoding formats for character sets, restricting character data fields to only contain alpha-numeric characters, prohibiting special characters, and validating schema structures.

In summary: know your formats, use only known formats, and consider only properly externalized (standardized, published, documented) formats to be "known" or knowable.

This is complementary to XSLT Blender since while it does not enforce this boundary, it enables cross-organizational support of the boundary for users and organizations who respect it (by using supported standards such as NISO STS or OSCAL).

Other known/knowable formats for these purposes include the 'big' XML-based standards: NISO JATS, TEI, OASIS DocBook, DITA, and many others of different kinds and to different degrees.

AC-6 Least Privilege

Inasmuch as all applications run entirely within the browser, access controls applying to the browser also apply to these applications. Browser controls regarding cross-origin scripting and resource sharing apply to these applications as well.

CM-7 Least Functionality

XSLT provides a 'functional black box' limited in interaction with the system. There is basically nothing that an XSLT engine can do other than hang up, error out, or deliver a result in a known form -- in the case of XSLT Blender, a DOM (document object instance). Since

The CM-7 control and its enhancements describe how to limit access and capabilities for systems to prevent unauthorized use by software. As does AC-4(14), these provisions explicitly make exception for software, like XSLT Blender, whose source code is given. (In the case of XSLT Blender applications, there are no binaries at all, as both XSLT and Javascript run as interpreted languages in the browser runtime.) Nonetheless, for any application developed and deployed on this model, the browser offers such a limited-privilege environment for extra security, helping to protect against either malicious or unintended breaches or failures.

CM-7(6) Confined Environments with Limited Privileges

CM-7(7) Code Execution in Protected Environments

If high sensitivity warrants the extra costs in monitoring, browser usage can be monitored and XSLT-Blender-based processes logged for traceability.

CM-7(8) Binary or Machine Executable Code

(a) Prohibit the use of binary or machine-executable code from sources with limited or no warranty or without the provision of source code

(b) allows exceptions to be made, but since XSLT Blender source code is always posted, always available and traceable, this control does not apply - no binaries are required to execute code in the (approved) installed base.

CM-10 Software Usage Restrictions

XSLT Blender and applications distributed with it on github.com/usnistgov/xslt-blender are in the public domain and not subject to usage restrictions based on IP or copyright.

CM-10(1) Open-source Software

XSLT Blender is all open source, its code available for inspection, assessment and third-party analysis and testing.

An Issues board provides a channel and venue for development and bug reports.

SA-11

Ongoing testing and evaluation are integrated into the development lifecycle for these applications. Every use is also expected to be an evaluation for continued fitness. As noted, Github Issues provide an infrastructure for bug reports and feature development.

SC-2 Separation of System and User Functionality

This control is served by the separation between the operating system, the browser runtime under the user's control, and the server providing for application software and resource distribution and availability.

SC-6 Resource Availability

SC-7 Boundary Protection

SC-27 Platform-independent Applications

XSLT Blender applications are built on relevant standards: HTML, CSS, Javascript (ECMAScript), XML and XSLT. Frequently an application may be scoped to a standardized form of XML. These standards provide a basis for platform independence by offering multiple implementations. To serve an XSLT Blender application requires only a generic (plain) web server configured to deliver the needed file formats via a single, well-secured protocol, https.

One easy way to see this principle in action is to try any XSLT Blender application in two different browsers.

Discussion: Platforms are combinations of hardware, firmware, and software components used to execute software applications. Platforms include operating systems, the underlying computer architectures, or both. Platform-independent applications are applications with the capability to execute on multiple platforms. Such applications promote portability and reconstitution on different platforms. Application portability and the ability to reconstitute on different platforms increase the availability of mission-essential functions within organizations in situations where systems with specific operating systems are under attack.

SC-36 Distributed Processing and Storage

XSLT Blender is maintained in Github, a cloud service, and served on the open Internet. Since each application runtime operates in isolation, without any communications back, users can process and store their data as they need and see fit, under their own controls.

SI-10 Information Input Validation

Generally, all inputs to an XSLT Blender application will be constrained to XML formats, that is using XML syntax. In itself this provides a level of input validation because syntactically incorrect inputs, failing to parse, will never be presented to the XSLT engine for processing.

Additionally, particular XML vocabularies can be validated, and particular projects may leverage this in their handling of these formats, relying on input validations to bound 'known' from 'unknown' inputs, for example to produce errors or warnings for the latter.

SI-10(3) Predictable Behavior

Since XSLT engines are compliant to an external specification, and many XSLT 1.0 processors have been written, conformance is relatively easy to test. Consequently XSLT 1.0 engines are highly predictable, both in principle, and in actuality as soon as a runtime configuration is known.

SI-10(5) Restrict Inputs to Trusted Sources and Approved Formats

Many projects implement this control enhancement, which in addition to offering security, helps to define exception handling in general.

For example the STS Viewer returns "no good" for inputs not recognized as NIST STS format.