application-level authorized software
163628·updated Oct 3, 2026A layer-scoped enforcement boundary within an authorized-software (allowlisting) control regime, specifically the granularity at which permitted-execution policy is applied to discrete, named software applications as whole units. It distinguishes coarse-grained controls that identify and permit or deny execution at the application boundary from finer-grained controls operating below that boundary — at the levels of APIs, modules, scripts, system processes, kernel functions, drivers, and dynamic-link libraries. The field uses it as a reference point for characterizing the *depth* of an allowlisting implementation: controls that act only at this layer can be bypassed by malicious code embedded within or loaded by an already-authorized application, which is why standards guidance calls for decomposing and monitoring software at sub-application levels to close that gap.
Source
Authorized software programs can be limited to specific versions or come from specific sources. To facilitate a comprehensive authorized software process and increase the strength of protection against attacks that bypass application-level authorized software, software programs may be decomposed into and monitored at different levels of detail. These levels include applications, application programming interfaces, application modules, scripts, system processes, system services, kernel functions, registries, drivers, and dynamic link libraries.the sentence this term was read in
generalized from a web lookup of the quoted expression, with 1 reviewed place(s) it is used as the term Verdict: compositional.
A definition generalized from search results is a draft to react to, not provenance. Confirm it against an authority document before this term is verified.
A web lookup ran when this term was proposed
A layer-scoped enforcement boundary within an authorized-software (allowlisting) control regime, specifically the granularity at which permitted-execution policy is applied to discrete, named software applications as whole units. It distinguishes coarse-grained controls that identify and permit or deny execution at the application boundary from finer-grained controls operating below that boundary — at the levels of APIs, modules, scripts, system processes, kernel functions, drivers, and dynamic-link libraries. The field uses it as a reference point for characterizing the *depth* of an allowlisting implementation: controls that act only at this layer can be bypassed by malicious code embedded within or loaded by an already-authorized application, which is why standards guidance calls for decomposing and monitoring software at sub-application levels to close that gap.
Advisory only. A term this product ships is defined by an authority document, not by a search result.
Proposed during multiword review of this document in the CKI mapping queue.
Attested in
Classifications
Entity Type
Sensitivity
Information Class
Variants
- plural
- application-level authorized softwares
- possessive
- application-level authorized software's
- pluralpossessive
- application-level authorized softwares'
Framework definitions
- §1 · attested_usage_reviewer_confirmed
- No definition is given in NIST SP 800-171r3. The term is attested in use at 1 citation in that document; a definition is pending curation.Increment 2: attested in NIST SP 800-171r3 without a glossary definition.
- §1 · web_lookup_draft
- A layer-scoped enforcement boundary within an authorized-software (allowlisting) control regime, specifically the granularity at which permitted-execution policy is applied to discrete, named software applications as whole units. It distinguishes coarse-grained controls that identify and permit or deny execution at the application boundary from finer-grained controls operating below that boundary — at the levels of APIs, modules, scripts, system processes, kernel functions, drivers, and dynamic-link libraries. The field uses it as a reference point for characterizing the *depth* of an allowlisting implementation: controls that act only at this layer can be bypassed by malicious code embedded within or loaded by an already-authorized application, which is why standards guidance calls for decomposing and monitoring software at sub-application levels to close that gap.Drafted by the propose-term web lookup (PD-018); a curator confirms or replaces it.