Sanitized Inputs check ignores Go and misclassifies non-app repositories

[filipenevola]

Summary

The GitHub Sanitized Inputs compliance check currently infers input validation only from a fixed dependency-name list in package.json, requirements.txt, pyproject.toml, or composer.json files.

This causes incorrect results for repositories in unsupported languages and for repositories that are not standalone applications:

• a Go CLI with extensive explicit argument, environment-variable, JSON, response, and state validation is reported as having no input validation because go.mod and Go validation patterns are not inspected;
• a Docker-based composite GitHub Action with only action.yml and workflows is failed because it has no dependency file, even though its inputs are typed by the action contract and forwarded to a validating CLI;
• conversely, a large repository can pass merely because a supported library appears in an example or unrelated subdirectory.

Reproduction

1. Connect GitHub to an organization with multiple repository types.
2. Include a Go application/CLI whose validation is implemented with standard-library parsing and explicit checks.
3. Include a GitHub Action repository with action.yml but no package manifest.
4. Include a monorepo containing a supported validation library only in an example or unrelated package.
5. Run the Sanitized Inputs check.

Actual result

• The Go repository and GitHub Action repository fail with No input validation library found.
• The monorepo passes based on the unrelated dependency match.
• The compliance task is failed even though dependency presence alone neither proves nor disproves effective input validation.

Observed again on 2026-08-16 in the hosted Comp AI platform: two repositories passed and two failed, with the failures based only on missing supported dependency files/names.

Expected result

Use an auditable result model that distinguishes:

1. supported-library detection;
2. unsupported language/repository type requiring manual evidence;
3. repository not applicable because it exposes no independent inbound interface; and
4. verified absence of validation.

Recommended improvements:

• support Go (go.mod) and common Go parsing/validation patterns;
• recognize GitHub Action metadata and delegated validation boundaries;
• allow per-repository applicability and evidence overrides with justification;
• scope dependency matches to relevant production packages instead of examples/tests alone; and
• report unsupported detection as needs review, not automatically as a failed control.

No organization IDs, connection IDs, run IDs, repository names, customer names, or private code are included in this report.

[linear-code]

COMP-294

[hampsterx]

Another case from a supported language, and what the file's own history says about the mechanism behind it.

A Python API that validates inbound requests with WTForms fails this check. PY_VALIDATION_PACKAGES in packages/integration-platform/src/manifests/github/checks/sanitized-inputs.ts (current as of 070a9642) is pydantic, marshmallow, cerberus, voluptuous, jsonschema, schematics, typeguard. A Pyramid service that declares wtforms and wtforms-alchemy in pyproject.toml and builds its forms directly off the request object reports No input validation library found. The language is supported and the manifest parses correctly; the library is simply not on the list.

The list grows one customer complaint at a time. 964cb1bf3 ("expand validation library detection", 2026-04-17) took JS from one entry to eleven, Python from one to seven, and added PHP outright, and its message records why: "Closes customer complaints surfaced in Slack (Yup, Joi, Marshmallow, Effect Schema, Laravel)." That is the part worth looking at rather than any single missing name. Every gap is found by a customer whose control sits failed until a release adds their library, WTForms is the next name in that queue, and Go is the same queue with nothing to add a name to.

The same commit widened the proxy in the other direction. laravel/framework and bare effect are on the lists deliberately, but neither is a validator. A Laravel app passes because the framework is a dependency, whether or not a single FormRequest or Validator::make call exists in it, and effect matches independently of @effect/schema, which is listed separately. So a pass can mean "the framework is installed".

One connection, four repos:

Repo	Validation	Result	What the result was based on
Python API, terminates untrusted input	WTForms + wtforms-alchemy	fail	name absent from the list
PHP API, terminates untrusted input	framework validation	pass	laravel/framework in composer.json
Browser SPA, no server surface	yup	pass	yup in package.json
Browser SPA, no server surface	none	fail	no manifest match

The two browser clients cannot hold a server-side input-validation control at all, and they return one pass and one fail. The two repos that do terminate untrusted input also return one of each. Every verdict is deterministic, and none of them was reached by looking at how input is validated.

The check does what its description says (Verifies repositories use a supported input-validation library), and the manual-evidence path in the failure text is presumably the intended answer for anything unsupported. Its cost is that it is per repo, repeated as repos are added, and the control reads as failed in the meantime on a repo where validation is not actually missing.

Which makes the direction the real question, and it looks like a platform one rather than a check one: CheckContext gives a check pass and fail and nothing else (packages/integration-platform/src/types.ts:334, :350), so needs review and not applicable are not states a check can emit today, however well it detects. The concept is not foreign to the codebase, the Aikido manifest already parses not_applicable straight off that vendor's compliance report (manifests/aikido/types.ts:140), it is just not in the vocabulary your own checks have. Is the intent to keep extending the per-language allowlists as complaints arrive, or to give checks that third state?

[hampsterx]

If the answer to that is "keep extending the lists", here is what one pass would look like, plus a second way the Python matcher gets it wrong that is worth folding into the same change.

The lists are not ordered by usage. Monthly downloads (PyPI, npm, Packagist, fetched today), listed entries against unlisted ones:

	On the list	Not on the list
Python	pydantic 1,180M · jsonschema 637M · marshmallow 124M · typeguard 76M · voluptuous 7.9M · cerberus 6.7M · schematics 0.79M	attrs 969M · msgspec 43M · djangorestframework 30M · flask-wtf 19M · wtforms 18M · webargs 3.6M
JS/TS	ajv 1,524M · zod 1,057M · effect 110M · joi 99M · valibot 70M · yup 52M · class-validator 46M · superstruct 24M · io-ts 11M · @effect/schema 4.6M · runtypes 1.1M	@sinclair/typebox 446M · validator 102M · express-validator 7.2M · arktype 6.0M
PHP	laravel/framework 13M · symfony/validator 6.9M · respect/validation 0.86M · vlucas/valitron 0.076M	webmozart/assert 14M · symfony/form 3.4M · beberlei/assert 1.8M · laminas/laminas-validator 1.2M · illuminate/validation 0.58M

WTForms outranks three of the seven Python entries, and TypeBox would come third on the JS list behind only ajv and zod. schematics has had no release since 2021-08-17. zendframework/zend-validator, which Packagist marks abandoned in favour of laminas/laminas-validator, still draws 119K a month against the 76K of vlucas/valitron, which is on the list. That is the shape of a list assembled from whoever complained, which is the point of the earlier comment rather than a criticism of any single choice.

Worth adding, in order:

• Python: msgspec (validates JSON against typed structs at decode time) · wtforms (form and field validators bound to request data) · flask-wtf (the WTForms integration many Flask repos declare instead of wtforms itself) · djangorestframework (serializers are the validation layer for most Django APIs) · webargs (parses and validates request arguments) · colander, formencode (small, but they are the validation layer in Pyramid and legacy Pylons/TurboGears apps).
• JS/TS: @sinclair/typebox (JSON-Schema-typed validation, a direct ajv/zod peer) · arktype (current-generation schema validator) · express-validator (request-body and param validation middleware, the most literal fit for this control in Express) · @vinejs/vine (AdonisJS request validation).
• PHP: illuminate/validation (Laravel's validator as a standalone component; today a Slim or Mezzio app using it fails while a full Laravel app passes on the framework alone) · laminas/laminas-validator plus the abandoned zendframework/zend-validator, since Composer records the old name and an exact-key match will not follow the rename · symfony/form · rakit/validation · yiisoft/validator · cakephp/validation.

Worth refusing, and for reasons that generalise:

• dompurify (246M) and sanitize-html (47M) are HTML sanitizers, output-side XSS defences. They match the name of the control and not the control.
• validator (102M) is a bag of string predicates (isEmail, isUUID). Real code uses it inside validation, but it is also a general string utility.
• attrs (969M) is a class-boilerplate library whose validators are optional, so listing it passes every attrs-using repo whether or not anything is validated. That is the same failure already present in bare effect and in laravel/framework.
• webmozart/assert (14M) and egulias/email-validator (16M) are mostly transitive, and are internal invariants and a format check rather than request validation.

Separately: the Python matcher passes on prose. checkPythonFile splits pyproject.toml on newlines and regex-matches each line, rather than parsing the TOML, so any line carrying a listed name as a standalone token matches, dependency or not. Both of these pass the check today with no validation library declared anywhere:

keywords = ["pydantic", "fastapi"]
description = "A migration helper away from marshmallow"

The second one is a project whose own description says it moved off a validation library, scored as having input validation. Same file, same repo, opposite error from the WTForms case: the line-based scan both misses real dependencies and matches things that are not dependencies. Reading [project].dependencies and [project.optional-dependencies] as TOML would close that side of it.