OSCAP(8)

🌸 NAME 🌸

oscap β€” the OpenSCAP command line tool πŸ’… and yes, she's from the System Administration Utilities crew (that's section 8 of the manual, iykyk).


✨ SYNOPSIS ✨

oscap [general-options] module operation [operation-options-and-arguments]

πŸ¦‹ DESCRIPTION πŸ¦‹

okay so. oscap is the Security Content Automation Protocol (SCAP) toolkit, and it's built on top of the OpenSCAP library. It hands you a whole bunch of different functions for the different SCAP specifications, which we call modules here. one tool, many vibes.

and the OpenSCAP tool claims to provide the capabilities of an Authenticated Configuration Scanner and an Authenticated Vulnerability Scanner, exactly as defined by The National Institute of Standards and Technology. no cap, that's literally what it says. πŸ‘‘


πŸ’– GENERAL OPTIONS πŸ’–

  • -V, --version β€” prints out the supported SCAP specifications, plus where the schema files, schematron files, CPE files, probes and supported OVAL objects live. it also dishes up a list of inbuilt CPE names. very "tell me everything about yourself" energy.
  • -h, --help β€” the help screen. that's it, that's the whole thing πŸŽ€

🌈 MODULES 🌈

  • info β€” works out the type of a file and prints info about it.
  • xccdf β€” the eXtensible Configuration Checklist Description Format.
  • oval β€” Open Vulnerability and Assessment Language.
  • ds β€” SCAP Data Stream.
  • cpe β€” Common Platform Enumeration.

🫢 COMMON OPTIONS FOR ALL MODULES 🫢

  • --verbose VERBOSITY_LEVEL β€” switches on verbose mode at whatever verbosity level you name. VERBOSITY_LEVEL has to be one of these exact four, bestie: DEVEL, INFO, WARNING, ERROR.
  • --verbose-log-file FILE β€” sets the filename to write that additional information into.

πŸ” INFO OPERATIONS πŸ”

[options] any-scap-file.xml

this module prints information about the SCAP content inside a file you name on the command line. it figures out the SCAP content type, the specification version, the date of creation, the date of import, and so on and so forth. the info module doesn't need any extra operation switch β€” she just knows. πŸ’…

for XCCDF files or SCAP source data stream files, the info module prints out the IDs of the incorporated profiles, components, and data streams. those IDs are literally the thing you use to specify the target for evaluation. so use the options --profile, --xccdf-id (or --oval-id), and --datastream-id respectively.

  • --fetch-remote-resources β€” allows the download of remote components that are referenced from the data stream.
  • --list-rules β€” prints the IDs of the XCCDF rules selected by the given profile, one per line. you must use this option together with --profile. the output is machine-readable and contains only rule IDs, no extra decoration, no glitter, just data ✨
  • --list-vars β€” prints the XCCDF Value IDs and their resolved values for the given profile, one per line, tab-separated. this option must be used together with --profile. the output is machine-readable.
  • --local-files DIRECTORY β€” instead of downloading remote data stream components from the network, use data stream components stored locally as files in the given directory. in place of the remote data stream component, OpenSCAP will attempt to use a file whose file name is equal to the @name attribute of the uri element inside the catalog element inside the component-ref element in the data stream β€” but only if such a file exists. this option works only with SCAP 1.3 source data streams. it can't be used with SCAP 1.2 source data streams. nope. not happening. 🚫
  • --profile PROFILE β€” shows info for the profile with the given ID.
  • --profiles β€” shows the profiles from the input file in the <id>:<title> format, one line per profile.
  • --references β€” shows the list of references available in each benchmark.

πŸ‘‘ XCCDF OPERATIONS πŸ‘‘

eval [options] INPUT_FILE [oval-definitions-files]

performs evaluation of the XCCDF document file you pass as INPUT_FILE. it prints the result of each rule to standard output, including the rule title, the rule id, and the security identifier (CCE). and optionally you can hand it an SCAP source data stream as the INPUT_FILE instead of an XCCDF file (see --datastream-id). options, we love options.

now, the exit-code tea, because this part matters β˜•:

  • oscap returns 0 if all the rules pass. slay.
  • if there's an error during evaluation, the return code is 1.
  • if there's at least one rule with either a fail or unknown result, oscap finishes with return code 2. 😭

unless --skip-validation is used, the INPUT_FILE gets validated using XSD schemas (which ones depends on the document type of INPUT_FILE) and gets rejected if it's invalid. no fake content allowed.

you may also specify OVAL Definition files as the last parameter, and then the XCCDF evaluation will proceed only with those specified files. otherwise, when the oval-definitions-files parameter is missing, the oscap tool will try to load all the OVAL Definition files referenced from the XCCDF automatically β€” and it searches in the same path as the XCCDF. 🧚

  • --profile PROFILE β€” selects a particular profile from the XCCDF document. if you pass "(all)" a virtual profile gets used that selects all groups and rules. main character profile energy, honestly.
  • --rule RULE β€” selects a particular rule from the XCCDF document. only this rule will be evaluated, and any other rules required by this rule won't be evaluated. the rule will use values according to the selected profile, and if no profile is selected, default values are used. this option can be used multiple times to specify multiple rules at once. 🎯
  • --skip-rule RULE β€” skips a particular rule from the XCCDF document. this option can be used multiple times to skip multiple rules at once. not me ignoring rules on purpose πŸ™ˆ
  • --reference NAME:IDENTIFIER β€” evaluates the rules matching the given reference. this option can be used to check for evaluating compliance with a particular policy requirement. rules that match the reference will be evaluated, other rules will be skipped and a result of notselected will be returned. the argument needs to be provided in the form NAME:IDENTIFIER (the colon is the separator), where NAME is the reference name used as the text of xccdf:reference elements that are children of the xccdf:Benchmark element, and IDENTIFIER is the text of an xccdf:reference element that is a child of a particular xccdf:Rule element which has the same @href value as the xccdf:reference element of the NAME value. this feature requires the SCAP content to be formed in the aforementioned way. for example:
--reference "cis:4.1.3.19"
--reference "anssi:BP28(R29)"

the list of references available in the given benchmark can be obtained by running the oscap info --references command. πŸ’–

  • --tailoring-file TAILORING_FILE β€” uses the given file for XCCDF tailoring. select the profile from the tailoring file to apply using --profile. if both --tailoring-file and --tailoring-id are specified, --tailoring-file takes priority. she wins, periodt.
  • --tailoring-id COMPONENT_REF_ID β€” uses the tailoring component in the input source data stream for XCCDF tailoring. the tailoring component must be specified by its Ref-ID (that's the value of the component-ref/@id attribute in the input source data stream). select the profile from the tailoring component to apply using --profile. again, if both --tailoring-file and --tailoring-id are specified, --tailoring-file takes priority.
  • --cpe CPE_FILE β€” uses the given CPE dictionary or language (auto-detected) for applicability checks. (some CPE names are provided by openscap β€” peep oscap --version for the inbuilt CPE names.)
  • --results FILE β€” writes the XCCDF results into FILE.
  • --results-arf FILE β€” writes results to a given FILE in Asset Reporting Format. it's recommended to use this option instead of --results when you're dealing with data streams. trusted source say so.
  • --stig-viewer FILE β€” writes the XCCDF results into FILE. the rule result IDs in FILE are modified according to the STIG references in the evaluated content. the FILE can simply be imported into DISA STIG Viewer. see https://public.cyber.mil/stigs/srg-stig-tools/ for information about DISA STIG Viewer.
  • --thin-results β€” Thin Results provides only a minimal amount of information in OVAL/ARF results. the --without-syschar option is automatically enabled whenever you use Thin Results. she comes as a package deal πŸŽ€
  • --without-syschar β€” don't provide system characteristics in OVAL/ARF result files.
  • --report FILE β€” writes an HTML report into FILE.
  • --oval-results β€” generates an OVAL Result file for each OVAL session used for evaluation. a file with the name original-oval-definitions-filename.result.xml will be generated for each referenced OVAL file in the current working directory. to change the directory where the OVAL files are generated, change the CWD using the cd command.
  • --check-engine-results β€” after the evaluation is finished, each loaded check engine plugin is asked to export its results. the export itself is plugin specific, so please refer to the documentation of the plugin for more details. that's on the plugin, not on us πŸ’…
  • --export-variables β€” generates OVAL Variables documents which contain external variables' values that were provided to the OVAL checking engine during evaluation. the filename format is original-oval-definitions-filename-session-index.variables-variables-index.xml.
  • --datastream-id ID β€” uses a data stream with that particular ID from the given data stream collection. if you don't give one, the first data stream is used. this only applies if you give a source data stream in place of an XCCDF file.
  • --xccdf-id ID β€” takes the component ref with the given ID from the checklists. this allows you to select a particular XCCDF component even in cases where there are multiple XCCDFs in a single data stream. if none is given, the first component from the checklists element is used.

(and bestie… this is literally only part one. keep scrolling πŸ‘€)

  • --benchmark-id _ID_ β€” okay so this one grabs a component ref from any data stream that points at a component with an XCCDF Benchmark whose @id attribute matches the string you gave, exactly. BUT bestie, real talk: this is not the recommended way to pick a component-ref. You're way better off using --xccdf-id and/or --datastream-id for precision. And --benchmark-id only even gets used when both --xccdf-id and --datastream-id are missing from the command line! Periodt.
  • --skip-validation β€” just… don't validate the input/output files. Skipping the vibe check. πŸ’…
  • --skip-signature-validation β€” don't validate digital signatures in digitally signed SCAP source data streams. (Yes, that's exactly as spicy as it sounds.)
  • --enforce-signature β€” only process digitally signed SCAP source data streams. If a data stream rolls up without a signature, it gets rejected. No signature, no entry. 🚫
  • --fetch-remote-resources β€” lets you download remote OVAL content that's referenced from XCCDF via check-content-ref/@href. Go get it, girl. 🌐
  • --local-files _DIRECTORY_ β€” instead of downloading remote data stream components from the network, use the ones stored locally as files in the given directory. Here's the tea: instead of the remote data stream component, OpenSCAP will try to use a file whose file name equals the @name attribute of the uri element inside the catalog element inside the component-ref element of the data stream β€” if such a file exists. This option works only with SCAP 1.3 source data streams. It can't be used with SCAP 1.2 source data streams. πŸ™…β€β™€οΈ
  • --remediate β€” runs XCCDF remediation while the XCCDF evaluation is happening. This automatically executes the content of XCCDF fix elements for failed rules, so it must be avoided unless you're working with trusted content. Using this option is always at your own risk. 😭
  • --show-rule-details β€” shows the rule description and rationale when results get reported. Receipts for every rule. 🧾

🩹 remediate MODULE

remediate [options] INPUT_FILE [oval-definitions-files]

This one is the post-scan glow-up: remediation after the fact. It assumes INPUT_FILE is the result of an oscap xccdf eval operation, and that input file must contain a TestResult element. What it does is run the XCCDF fix elements for every failed rule-result sitting inside that TestResult. And yes, using this option is always at your own risk and should be avoided unless your content is trusted. πŸ”₯

  • --result-id _ID_ β€” the ID of the XCCDF TestResult element that's gonna get remediated. If you don't pass this option, the last TestResult (in top-down processing) gets remediated instead.
  • --skip-validation β€” do not validate input/output files. Skipping the check, living dangerously. πŸ’€
  • --fetch-remote-resources β€” allow downloading of remote OVAL content referenced from XCCDF by check-content-ref/@href.
  • --local-files _DIRECTORY_ β€” instead of downloading remote data stream components from the network, use data stream components stored locally as files in the given directory. Instead of the remote data stream component, OpenSCAP will attempt to use a file whose file name equals the @name attribute of the uri element within the catalog element within the component-ref element in the data stream, if such a file exists. Works only with SCAP 1.3 source data streams. Can't be used with SCAP 1.2 source data streams. πŸ’…
  • --cpe _CPE_FILE_ β€” use the given CPE dictionary or language (auto-detected) for applicability checks.
  • --results _FILE_ β€” write XCCDF results into FILE.
  • --results-arf _FILE_ β€” writes results to the given FILE in Asset Reporting Format. When you're dealing with data streams, it's recommended to flex this option instead of --results. ✨
  • --stig-viewer _FILE_ β€” writes XCCDF results into FILE. The rule result IDs in FILE get modified according to STIG references in the evaluated content. The FILE can then be imported straight into DISA STIG Viewer. For info about DISA STIG Viewer, see https://public.cyber.mil/stigs/srg-stig-tools/
  • --report _FILE_ β€” write an HTML report into FILE. Pretty results, we love to see it. πŸŽ€
  • --oval-results β€” generate an OVAL Result file for each OVAL session used for evaluation. A file named original-oval-definitions-filename.result.xml will be generated for each referenced OVAL file.
  • --check-engine-results β€” after evaluation finishes, every loaded check engine plugin gets asked to export its results. The export itself is plugin-specific, so please refer to the documentation of the plugin for the details.
  • --export-variables β€” generate OVAL Variables documents containing the external variables' values that were provided to the OVAL checking engine during evaluation. The filename format is original-oval-definitions-filename-session-index.variables-variables-index.xml. πŸ¦‹
  • --progress β€” switches to sparse output suitable for progress reporting. The format of the output is "$rule_id:$result\n".
  • --progress-full β€” switches to sparse but a lil' more saturated output, also suitable for progress reporting. The format of the output is "$rule_id|$rule_title|$result\n".

🧚 resolve MODULE

resolve -o output-file xccdf-file

Resolve an XCCDF file the way the XCCDF specification describes. It flattens the inheritance hierarchy of XCCDF profiles, groups, rules and values. The result is another XCCDF document, which gets written to output-file. It's giving ✨ un-nested ✨.

  • --force β€” force resolving the XCCDF document even if it's already marked as resolved. Stubborn girl energy. πŸ’…

βœ… validate MODULE

validate [options] xccdf-file

Validates the given XCCDF file against an XML schema. Every error found gets printed to standard error. The return code tells you everything:

  • 0 β€” if validation succeeds πŸŽ‰
  • 1 β€” if validation could not be performed due to some error 😭
  • 2 β€” if the XCCDF document is not valid πŸ’€
  • --skip-schematron β€” turn off Schematron-based validation. Schematron is able to find more errors and inconsistencies, but it's much slower. Also FYI: Schematron is available only for XCCDF version 1.2.

πŸ“¦ export-oval-variables MODULE

export-oval-variables [options] xccdf-file [oval-definitions-files]

Collects all the XCCDF values that would be used by OVAL during evaluation of a certain profile, and exports them as OVAL external-variables document(s). The filename format is original-oval-definitions-filename-session-index.variables-variables-index.xml. So organized. πŸŽ€

  • --profile _PROFILE_ β€” select a particular profile from the XCCDF document.
  • --fetch-remote-resources β€” allow download of remote OVAL content referenced from XCCDF by check-content-ref/@href.
  • --local-files _DIRECTORY_ β€” instead of downloading remote data stream components from the network, use data stream components stored locally as files in the given directory. In place of the remote data stream component, OpenSCAP will attempt to use a file whose file name is equal to the @name attribute of the uri element within the catalog element within the component-ref element in the data stream, if such a file exists. This option works only with SCAP 1.3 source data streams. It can't be used with SCAP 1.2 source data streams. πŸ™ˆ
  • --skip-validation β€” do not validate input/output files.
  • --datastream-id _ID_ β€” uses a data stream with that particular ID from the given data stream collection. If it's not given, the first data stream is used. Only applies if you give an SCAP source data stream in place of an XCCDF file.
  • --xccdf-id _ID_ β€” takes the component ref with the given ID from checklists. This lets you select a particular XCCDF component even in cases where there are 2 XCCDFs in one data stream. Two girls, one file. πŸ’œ
  • --benchmark-id _ID_ β€” selects a component ref from any data stream that references a component with an XCCDF Benchmark such that its @id attribute matches the given string exactly. Please note that this is not the recommended way of selecting a component-ref. You're advised to use --xccdf-id and/or --datastream-id for more precision. --benchmark-id is only used when both --xccdf-id and --datastream-id are not present on the command line!
  • --cpe _CPE_FILE_ β€” use the given CPE dictionary or language (auto-detected) for applicability checks. The variables documents are created only for xccdf:Rules which are applicable.

🌈 generate MODULE

generate [options] <submodule> [submodule-specific-options]

Generates another document from an XCCDF file β€” think security guide or result report. So many possibilities. ✨

  • --profile _ID_ β€” apply the profile with the given ID to the Benchmark before further processing takes place.

Available submodules: πŸ‘‘

🌸 guide SUBMODULE

guide [options] xccdf-file

Generates an HTML document containing a security guide from an XCCDF Benchmark. Unless the --output option is specified, it will be written to standard output. And heads up: without a profile being set, only groups (not rules) will be included in the output. 🫢

  • --output _FILE_ β€” write the guide to this file instead of standard output.
  • --hide-profile-info β€” this option has no effect and is kept only for backward compatibility purposes. It's a legacy icon, we keep her around for the memories. πŸ’€
  • --benchmark-id ID β€” hunts down a component ref in any datastream that points at a component whose XCCDF Benchmark @id attribute is exactly this string. no fuzzy matching bestie, exact or nothing πŸ’…
  • --xccdf-id ID β€” grabs the component ref with this ID out of the checklists. why do we need it? because some datastreams are messy and carry multiple XCCDFs, and this lets you pick your fave πŸŽ€ if you don't pass it, you just get the first component from the checklists element. default behaviour, no thoughts, head empty ✨
  • --tailoring-file TAILORING_FILE β€” use this file for XCCDF tailoring. then pick which profile from the tailoring file to apply with --profile. πŸ‘‘ and if you pass both --tailoring-file and --tailoring-id? the file WINS, it takes priority, periodt.
  • --tailoring-id COMPONENT_REF_ID β€” use the tailoring component inside your input source datastream for XCCDF tailoring. it has to be named by its Ref-ID (that's the value of the component-ref/@id attribute in the input source datastream, iykyk). then select the profile to apply from the tailoring component using --profile. and again β€” if both --tailoring-file and --tailoring-id are around, --tailoring-file takes priority, no debate 🌸
  • --skip-signature-validation β€” do not validate digital signatures in digitally signed SCAP source datastreams. skippin the vibe check, we love a risk taker πŸ™ˆ
  • --enforce-signature β€” process only digitally signed SCAP source datastreams. if a datastream has no signature and you flip this switch on, it gets rejected. πŸ”₯ strict queen behaviour

✨ report ✨

report [options] xccdf-file

Spits out an HTML document stuffed with the results of an XCCDF Benchmark execution πŸŽ€ and unless you say otherwise with --output, it just goes straight to standard output.

  • --output FILE β€” write the report to this file instead of standard output. your terminal will thank you πŸ’–
  • --result-id ID β€” the ID of the XCCDF TestResult that the report gets generated from.

✨ fix ✨

fix [options] xccdf-file

Generates a script that's supposed to bring your system into a state of compliance with the given XCCDF Benchmark πŸ› οΈβœ¨

now here's the tea β€” there are 2 possibilities when generating fixes:

  • Result-oriented fixes (--result-id)
  • Profile-oriented fixes (--profile)

Result-oriented takes precedence over Profile-oriented. so if result-id is given, oscap will ignore any profile you handed it. literally just zoning it out πŸ’€

Result-oriented fixes are built using the result-id you provide to select only the failing rules from results in xccdf-file β€” it skips all the other rules.

⚠️ heads up bestie: it isn't possible to generate result-oriented fixes for the kickstart and bootc fix type. that combo just doesn't exist, no cap.

Profile-oriented fixes are generated using all rules within the provided profile. and if you provide no result-id and no profile? the (default) profile gets used to generate fixes. it'll pick for you 🫢

  • --fix-type TYPE β€” specify the fix type. there are multiple programming languages your fix script can come out in, which is genuinely iconic. TYPE should be one of: bash, ansible, puppet, anaconda, ignition, kubernetes, blueprint, kickstart, bootc. default is bash. 🌈
  • --output FILE β€” write the report to this file instead of standard output.
  • --result-id ID β€” fixes will be generated for the failed rule-results of the specified TestResult.
  • --xccdf-id ID β€” takes the component ref with the given ID from checklists. this lets you select a particular XCCDF component even when there are multiple XCCDFs chillin in a single datastream ✨ if none is given, the first component from the checklists element is used.
  • --benchmark-id ID β€” selects a component ref from any datastream that references a component with an XCCDF Benchmark whose @id attribute matches the given string exactly.
  • --tailoring-file TAILORING_FILE β€” use this file for XCCDF tailoring. select the profile from the tailoring file to apply using --profile. if both --tailoring-file and --tailoring-id are specified, --tailoring-file takes priority πŸ‘‘
  • --tailoring-id COMPONENT_REF_ID β€” use the tailoring component in the input source datastream for XCCDF tailoring. the tailoring component has to be specified by its Ref-ID (that's the value of the component-ref/@id attribute in the input source datastream). select the profile to apply from the tailoring component using --profile. if both --tailoring-file and --tailoring-id are specified, --tailoring-file takes priority πŸ’…
  • --skip-signature-validation β€” do not validate digital signatures in digitally signed SCAP source datastreams.
  • --enforce-signature β€” process only digitally signed SCAP source datastreams. datastreams without a signature get rejected if this switch is used. 🚫

✨ custom ✨

custom --stylesheet xslt-file [options] xccdf-file

Generate a custom output from an XCCDF file β€” whatever the XSLT file you hand it decides the output should look like. build-a-bear but for documents 🧚

  • --stylesheet FILE β€” specify an absolute path to a custom stylesheet to format the output. absolute, bestie, not a relative path, we're being precise here.
  • --output FILE β€” write the document into file. πŸ“

πŸ’– OVAL OPERATIONS πŸ’–

Okay bestie, this is the OVAL corner of the tool and it's giving very thorough. Like, we're checking your whole system against a definition file and reporting back on every single one. Let's go. πŸ¦‹


🌸 eval [options] INPUT_FILE

Probe your system and evaluate every definition from the OVAL Definition file. The result of each definition gets printed to standard output. Return code is 0 after a successful evaluation, and on error, value 1 is returned. Periodt.

INPUT_FILE can be either an OVAL Definition File or an SCAP source data stream β€” it depends on the options you used. Choose your fighter. πŸ’…

Unless --skip-validation is used, INPUT_FILE gets validated using XSD schemas (depending on the document type of INPUT_FILE), and if it's invalid it gets rejected. No fake ones allowed. 🚫
  • --id DEFINITION-ID β€” Evaluate ONLY the specified OVAL Definition from the OVAL Definition File. Just the one. The main character. πŸ‘‘
  • --variables FILE β€” Provide external variables that the OVAL Definition File expects.
  • --directives FILE β€” Use OVAL Directives content to specify the desired results content.
  • --without-syschar β€” Don't include system characteristics in the result file.
  • --results FILE β€” Write OVAL Results into a file.
  • --report FILE β€” Create a human readable (HTML) report from OVAL Results. Cute AND functional. ✨
  • --datastream-id ID β€” Uses a data stream with that particular ID from the given data stream collection. If it's not given, the first data stream is used. This only applies if you hand over a source data stream in place of an OVAL file.
  • --oval-id ID β€” Takes the component ref with the given ID from checks. This lets you select a particular OVAL component even in cases where there are multiple OVALs in a single data stream. Choices, choices. πŸ™ˆ
  • --skip-validation β€” Do not validate input/output files.
  • --fetch-remote-resources β€” Allow download of remote components referenced from the data stream. It goes and gets them. 🧚
  • --local-files DIRECTORY β€” Instead of downloading remote data stream components from the network, use data stream components stored locally as files in the given directory. In place of the remote data stream component, OpenSCAP will attempt to use a file whose file name is equal to the @name attribute of the uri element within the catalog element within the component-ref element in the data stream β€” if such a file exists. This option works only with SCAP 1.3 source data streams. It can't be used with SCAP 1.2 source data streams. Sorry babe, 1.2 girlies are not invited to this party. πŸ’€

🌈 collect [options] definitions-file

Probe the system and gather system characteristics for all objects in the OVAL Definition file. Collecting intel. πŸ•΅οΈβ€β™€οΈ

  • --id OBJECT-ID β€” Collect system characteristics ONLY for the specified OVAL Object.
  • --variables FILE β€” Provide external variables that the OVAL Definitions expect.
  • --syschar FILE β€” Write OVAL System Characteristic into a file.
  • --skip-validation β€” Do not validate input/output files.

πŸ¦‹ analyse [options] --results FILE definitions-file syschar-file

In this mode, the oscap tool does not perform data collection on the local system β€” instead it relies upon the input file, which may have been generated on another system. Different machine, same drama. The output (OVAL Results) gets printed to the file specified by the --results parameter.

  • --variables FILE β€” Provide external variables that the OVAL Definitions expect.
  • --directives FILE β€” Use OVAL Directives content to specify the desired results content.
  • --skip-validation β€” Do not validate input/output files.

⭐ validate [options] oval-file

Validate the given OVAL file against an XML schema. Every single error found gets printed to standard error, no filter, fr fr. Return code is 0 if validation succeeds, 1 if validation could not be performed due to some error, and 2 if the OVAL document is not valid.

  • --definitions, --variables, --syschar, --results --directives β€” The type of the OVAL document is automatically detected by default. If you want to enforce a certain document type, you can use one of these options.
  • --skip-schematron β€” Turn off Schematron-based validation. It's able to find more errors and inconsistencies, but it's much slower. Highkey worth it, lowkey a wait. 😭

πŸŽ€ generate <submodule> [submodule-specific-options]

Generate another document from an OVAL file. Transformation era. ✨

Available submodules:

report [options] oval-results-file

Generate a formatted HTML page containing a visualisation of an OVAL results file. Unless the --output option is specified, it will be written to standard output.

  • --output FILE β€” Write the report to this file instead of standard output.

🫢 CPE OPERATIONS 🫢

Short and sweet, we love a concise queen. πŸ’œ

  • check name β€” Check whether name is in the correct CPE format.
  • match name dictionary.xml β€” Find an exact match of the CPE name in the dictionary.
  • validate cpe-dict-file β€” Validate the given CPE dictionary file against an XML schema. Every found error gets printed to standard error. Return code is 0 if validation succeeds, 1 if validation could not be performed due to some error, 2 if the XCCDF document is not valid.
Nope, you read that right β€” it says "XCCDF document" in the CPE validate exit-code description. We're keeping it exactly as the page says it. No notes. πŸ™ˆ

πŸ’… DS OPERATIONS πŸ’…

Data stream business, let's get into it. 🌈

  • sds-validate SOURCE_DS β€” Validate the given source data stream file against an XML schema. Every found error is printed to standard error. Return code is 0 if validation succeeds, 1 if validation could not be performed due to some error, 2 if the source data stream is not valid.
  • rds-validate SOURCE_RDS β€” Validate the given result data stream file against an XML schema. Every found error is printed to standard error. Return code is 0 if validation succeeds, 1 if validation could not be performed due to some error, 2 if the result data stream is not valid.

πŸ› REPORTING BUGS πŸ›

Please report bugs using https://github.com/OpenSCAP/openscap/issues

Make sure you include the full output of oscap --v in the bug report. Like, the full thing, bestie β€” don't be shy with it, it's literally how they help you. 🫢


πŸ‘‘ AUTHORS πŸ‘‘

  • Peter Vrabec <pvrabec@redhat.com>
  • Ε imon LukaΕ‘Γ­k
  • Martin Preisler <mpreisle@redhat.com>

And that's the whole page, babes!! 🌸 This manual page is brought to you by Red Hat, dated March 2021, and it's page OSCAP(8). You read the entire thing β€” that's iconic behaviour, genuinely. Go eval something and slay. πŸ’–βœ¨πŸŽ€