Inputs, checked before they are trusted.
SI-10 (information input validation) is the NIST 800-53 control that says a system should check the validity of the inputs it accepts. Unvalidated input is how a request gets a system to do something it should not: read a file outside its directory, call a host it should not, or process malformed data. The validation lives in the code that takes the input, and it is easy to remove without anyone noticing the consequence.
The shapes the same control failure takes.
Input validation weakens when a change lets untrusted input through unchecked. The recurring shapes:
A file path is built from unvalidated input
A user-supplied name is joined into a path with no check, so a crafted value with ../ can escape the intended directory (path traversal).
A URL or host comes from unvalidated input
A request target is taken from input without an allowlist, so the server can be made to call internal or unintended hosts (server-side request forgery).
A validation check is removed
A check on an input's format, range, or allowed set is dropped, so malformed or hostile values now reach the logic behind it.
Bounds or length checks are removed
Size or length limits on input are taken out, so oversized or malformed payloads get through.
An allowlist is replaced by accepting anything
A strict allowlist of accepted values is loosened to accept arbitrary input, widening what a caller can supply.
A download path built from an unvalidated name.
A download endpoint serves files from an upload directory by name. A change passes the user's filename straight into the path and drops the allowlist check, so a request for a crafted name escapes the directory and reads files it should not.
function download(name) {- if (!isAllowedFile(name)) return notFound() return readFile(path.join(UPLOAD_DIR, name))}Without the check, a crafted name like ../../etc/passwd escapes the upload directory (path traversal) and reads arbitrary files. SI-10 (information input validation) expects inputs to be checked for validity. Validate the name against an allowlist, or resolve the path and confirm it stays within the directory before reading.
Input validation is checked where untrusted data enters.
An assessment under NIST 800-53 looks at whether a system validates the inputs it accepts at its trust boundaries: are file names, URLs, identifiers, and payloads checked before they are used. A change that removed a validation or built a path or request from raw input is the concrete weakness behind that, and it is visible in the diff to the handler.
A review, not a full SAST suite.
heygrc flags changes that touch SI-10 and cites the control so the fix happens in the pull request. It is not a replacement for your static analysis or fuzzing. It catches the moment a change lets untrusted input through unchecked, at the diff. heygrc is in early access.