Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some complex but valid Metapath in constraint targets do not produce functional Inspector XSLTs. #91

Open
2 tasks
wendellpiez opened this issue Dec 4, 2023 · 0 comments
Labels
bug Something isn't working

Comments

@wendellpiez
Copy link
Collaborator

Describe the bug

Some Metaschema-based techs including OSCAL use Metapath syntax in targeting constraints, which break the current (beta-version) InspectorXSLT.

This happens any time a path does not conform to the definition of the syntax for selection patterns) in XSLT, which is narrower than XPath, for example forbidding the form.

information-type/(confidentiality-impact|integrity-impact|availability-impact)/(base|selected)

https://github.com/usnistgov/OSCAL/blob/f159b28948cb0034370fb819a45bfdaeaef5192a/src/metaschema/oscal_ssp_metaschema.xml#L291C8-L291C8

and then there is, in an index definition --

control-implementation/implemented-requirement//by-component|doc(system-implementation/leveraged-authorization/link[@rel='system-security-plan']/@href)/system-security-plan/control-implementation/implemented-requirement//by-component

https://github.com/usnistgov/OSCAL/blob/f159b28948cb0034370fb819a45bfdaeaef5192a/src/metaschema/oscal_ssp_metaschema.xml#L49C47-L49C280

A couple of possible mitigations:

  • Consider rewriting these expressions when mapping to templates - a Metapath->XPath conversion
  • Reconsider this implementation strategy, if the disparity between Metapath and XPath patterns (as a subset of expressions) continues to grow.

These are not exclusive and the first could be done while planning the second.

The option of rewriting the patterns 'by hand' might also be considered as a mitigation, which doesn't require parsing.

Who is the bug affecting?

Anyone with a metaschema using the problematic expressions.

This includes OSCAL users, a significant constituency.

What is affected by this bug?

InspectorXSLT is not available as an option for these users.

When does this occur?

Reliably.

How do we replicate the issue?

Try composing and producing an InspectorXSLT from an OSCAL schema.

NB: a solution should be accompanied by unit tests!

(More details available and tbd.)

Expected behavior (i.e. solution)

  • Functional InspectorXSLT implementations from OSCAL metaschemas.
  • A solution for any valid and conformant metaschema
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant