Yes. Extras pull in optional dependencies, and environment markers make a dependency conditional on the platform or Python version. A scan that reads a requirement without resolving it may report packages you never install, or miss ones you do. Scan the resolved result for each target environment.
Definitions
An extra is an optional group of dependencies a package defines. In requests[security] the bracketed name asks for the extra dependencies the project lists under security. PEP 508 says multiple extras are unioned together.
An environment marker follows a semicolon and is evaluated on the target system. When it evaluates to false, the dependency specification is ignored. Common variables include sys_platform, os_name and python_version.
The PEP's own example combines everything:
requests [security,tests] >= 2.8.1, == 2.8.* ; python_version < "2.7"
Why scan results differ
| Situation | Effect on a scan |
|---|---|
| Marker false on the scan machine | A tool that evaluates markers drops the package, one that does not may list it |
| Marker true only on Windows, scan on Linux | The Windows only package is invisible to the Linux scan |
| Extra not requested | Its dependencies never install, and should not appear |
| Extra requested in production only | A scan of a test environment misses it |
Neither answer is wrong in isolation. The question is which environment you ship.
How to scan the right thing
- List the targets you deploy: operating system, architecture and Python version.
- Generate a resolved lock for each target, or scan the installed environment inside the build image.
- Scan each result and keep the outputs separate.
- Compare the lists. Differences should be explained by markers and extras, not by surprise.
A lockfile that records every platform variant is the best input, because it removes the evaluation step from the scanner. OSV-Scanner's own documentation notes that manifest files can declare version ranges and do not necessarily record the versions installed in an environment, and advises preferring a resolved lockfile. See also whether pip audit works on unpinned requirements.
What to ask a vendor
- Does the tool evaluate markers, and for which platform?
- Can it scan an installed environment or a built image instead of a file?
- Does the report say which extras were assumed?
Safeguard's SBOM and dependency scanning accepts several inputs, including built images, and the free scan at https://gold.safeguard.sh/scan takes a manifest.
Quick check
What does a false environment marker do?
The dependency specification is ignored on that system, so the package is not installed there.
Should I scan requirements.txt or the built image?
The built image or resolved lock reflects what ships. A raw requirements file can include conditional or unresolved entries.
Sources
Last reviewed: 19 October 2026.
