Request for classic confinement ansible-security-scanner

name: ansible-security-scanner

description: Static SAST scanner for Ansible content (playbooks, roles, collections, task files, vars, and inventories). Detects malicious code, remote code execution, command and template injection, hardcoded credentials, supply-chain risk, unauthorized cloud access, lateral movement, and reverse shells. Over 1,000 rules across 30+ categories, with remediation guidance and mappings to CWE, OWASP Top 10, OWASP ASVS, MITRE ATT&CK, NIST, and CIS. Outputs SARIF, CycloneDX SBOM, GitLab SAST, JUnit, JSON, HTML, and Markdown.

snapcraft: ansible-security-scanner/snap/snapcraft.yaml at main · cpeoples/ansible-security-scanner · GitHub

upstream: GitHub - cpeoples/ansible-security-scanner: 🛡️ Static security scanner (SAST) for Ansible playbooks, roles, and collections. 1,000+ rules across 30+ categories detecting malicious code, RCE, hardcoded credentials, and supply-chain risk. Outputs SARIF, CycloneDX SBOM, and GitLab SAST. SLSA Build Level 3, Sigstore-signed. · GitHub

upstream-relation: I am the author and maintainer of the upstream project.

supported-category: debug tools

reasoning: This is a command-line security-analysis tool that the user points at arbitrary filesystem locations to scan. Users run it against Ansible content that lives outside $HOME in unpredictable, system-managed paths, for example --directory /etc/ansible, /opt/<role>, /srv, CI checkout directories, and mounted volumes, and it writes report artifacts (SARIF, SBOM, JSON, HTML) to arbitrary user-chosen output paths. The set of paths is entirely determined by the invoking user at runtime and is not known ahead of time.

Under strict confinement the tool is limited to $HOME (plus removable-media/system-files interfaces for a few fixed locations), so it cannot read the arbitrary source trees it is meant to scan nor write reports to arbitrary destinations. The home interface does not cover /etc, /opt, /srv, or other absolute paths, and there is no interface that grants read/write to arbitrary user-specified filesystem locations, which is the core requirement of a general-purpose file scanner.

I understand that strict confinement is generally preferred over classic.

I’ve tried the existing interfaces to make the snap work under strict confinement. With strict confinement plus the home interface, scans of content outside $HOME (for example /etc/ansible and /opt) fail with permission-denied errors, and snappy-debug confirms the denials are for read/write access to those arbitrary absolute paths, which no available interface covers.

This request has been added to the queue for review by the @reviewers team.

Hi @cpeoples,

I do not think that the tool fits in the debug-tools category which is a hard requirement for classic. And as per Process for reviewing classic confinement snaps , access to arbitrary location is listed under unsupported category for classic. That is why, I am unable to grant this request.

I would suggest to reconsider using $HOME interface as that should be enough to cover most of the use cases.