Audit Logs, SBOM, and Vulnerabilities

Purpose and Scope

This page orients operators, security reviewers, and maintainers around three related security operations topics in Apache Airflow: audit logs, software bill of materials files, and vulnerability handling. Audit logs help teams investigate who changed or triggered behavior inside an Airflow deployment. SBOMs help teams understand the components included in an Airflow distribution or image. Vulnerability handling defines how suspected flaws, dependency findings, and security scan results should be routed. The repository security policy is the authoritative source for how to report undisclosed vulnerabilities and how the Airflow security team expects reports to be framed. Sources: .github/SECURITY.md

Airflow’s public security documentation treats these topics as part of the broader Security section, alongside the security model, JWT authentication, Kerberos, workload security, secrets, and releasing security patches. That placement matters because audit trails, component inventories, and vulnerability reports are not isolated features. They are evidence used to operate Airflow safely, assess exposure, and communicate responsibly with the project. For a deployment team, the practical workflow is to collect local evidence from logs and inventories, decide whether the issue is an operational concern or an undisclosed vulnerability, and then use the right channel for the class of issue.

The most important boundary in the checked-in policy is that undisclosed vulnerabilities must not be filed as public GitHub issues. The document explicitly warns that GitHub issues are public and directs people with Airflow security concerns or suspected vulnerabilities to contact the Airflow security team by email. It also narrows the purpose of that address: it is for undisclosed security vulnerabilities in Apache Airflow and the process of fixing them, not general troubleshooting, normal bug reports, or broad security-related questions. Sources: .github/SECURITY.md

Relevant Source Files

• .github/SECURITY.md — Defines the project’s vulnerability reporting channel, explains what should and should not be reported to the security address, asks for one plain-text report per vulnerability, directs readers to the Airflow security documentation, and clarifies the treatment of dependency and Docker image scan findings.

Operational Concepts

An audit log is a record intended to support accountability and investigation. In Airflow, the official documentation distinguishes audit logs from event logs and organizes material around accessing audit logs, understanding their scope, common audit scenarios, event catalogs, and query methods. The operational reader should think of audit logs as investigation data: they answer questions such as which user action occurred, which task instance event changed state, or which command-line activity needs to be reviewed. They are especially useful when a team needs to correlate a user-visible action with runtime state changes or when an administrator needs to demonstrate how a workflow was modified.

An SBOM, or software bill of materials, is an inventory of software components. The official Airflow security documentation identifies SBOM as a dedicated security topic and describes SBOM files as critical. In security operations, the value of an SBOM is that it gives a reviewer a structured starting point for dependency analysis. When a vulnerability advisory names a package, a version, or a transitive dependency, an SBOM can help determine whether a particular Airflow installation or container image includes the affected component. It does not by itself prove exploitability; it is evidence for the next step in the risk assessment.

A dependency vulnerability finding is a claim that one of the third-party packages associated with an Airflow installation has a known issue. The official documentation separates this topic under vulnerabilities in third-party dependencies and includes guidance for how users should treat known CVEs, how constraints in released Airflow versions relate to those findings, and what to do when a CVE is detected. The repository policy reinforces that not every scan result belongs on the confidential vulnerability channel, especially when the report is a list of dependencies in the Airflow Docker reference image rather than an undisclosed flaw in Airflow itself. Sources: .github/SECURITY.md

System-to-Code Mapping

The checked-in security policy is not a runtime logging implementation, but it is a source-level contract for security communication. It starts by identifying itself as Apache Airflow Security guidance and states that it contains information about how to report vulnerabilities and how reported issues are handled. It points readers to the broader Airflow security documentation for deeper operational topics. In practice, that means audit log review, SBOM inspection, and dependency scanning should produce evidence, but the decision to contact the security team should follow the policy’s reporting criteria. Sources: .github/SECURITY.md

The policy also defines the boundary between confidential vulnerability handling and ordinary community support. It says the security email address should only be used to report undisclosed security vulnerabilities and to manage the process of fixing them. Regular bug reports, general questions, and unrelated security queries should use normal Airflow community channels instead. This distinction helps protect sensitive issues while keeping the security team focused on reports that require private coordination. For teams building internal runbooks, this boundary should be captured as an escalation rule rather than left to individual judgment. Sources: .github/SECURITY.md

The Docker image and dependency-scan language is particularly important for SBOM and vulnerability operations. The policy says that results of security scans containing a list of Airflow dependencies or dependencies in the Airflow Docker reference image are ignored by the security address, and it points readers toward documentation that explains how the Airflow reference image is fixed at release time and how users can build their own images and manage dependencies. The operational implication is that dependency inventories should be evaluated in the context of the deployed image, pinned constraints, and user-managed additions rather than treated as automatic upstream vulnerability reports. Sources: .github/SECURITY.md

Vulnerability Triage Flow

Start with evidence collection. If the concern is a suspicious change, unexpected task state, or user action, gather the relevant audit and event log records from the Airflow deployment before deciding whether it is a product vulnerability. If the concern is a dependency advisory, compare the affected package and version against the installation’s package inventory, constraints, image contents, or SBOM. If the concern is a suspected flaw in Airflow behavior, document how it affects Airflow security rather than only listing symptoms. This preparation makes the later decision more accurate and avoids mixing operational incidents with upstream vulnerability disclosure.

Next, classify the issue against the Airflow security model. The policy asks reporters to read and understand the Airflow security model before reporting because some issues that are valid for internet-facing systems are not valid for Airflow. The provided policy text explicitly notes that Airflow is not designed to be used by untrusted users, which is a key assumption when assessing whether an action is a vulnerability or a consequence of the deployment’s trust model. This step is where audit log evidence and SBOM data become context for a security judgment rather than standalone proof. Sources: .github/SECURITY.md

If the issue appears to be an undisclosed Airflow vulnerability, use the confidential reporting path. The policy requests one plain-text email for each vulnerability, including an explanation of how it affects Airflow security. It also says the team may ask for resubmission if the report is sent as an image, movie, HTML, or PDF attachment when plain text would have been sufficient. A good report should therefore describe the affected Airflow behavior, the deployment assumptions, steps to reproduce when safe to share, observed impact, relevant versions, and any audit log or dependency evidence needed to understand the risk. Sources: .github/SECURITY.md

If the issue is not an undisclosed vulnerability, do not use the security email address. Public bugs, user questions, configuration problems, and generalized scan output should follow normal community or operational channels. For dependency findings in an Airflow image, the policy directs readers toward the Docker stack guidance about fixed reference images and building custom images. This prevents the vulnerability channel from becoming a scanner inbox and encourages operators to take ownership of the dependencies they add, override, or ship in their own environments. Sources: .github/SECURITY.md

Practical Examples

Consider a user-action investigation. An administrator notices that a production DAG was paused before an expected run. The first response is not to file a vulnerability report; it is to review Airflow audit or event log entries, identify the acting user or interface, and confirm whether the action was authorized. If the logs show normal authorized behavior, the result is an internal governance or process issue. If the investigation reveals that a user could perform an action that should have been denied under the configured security model, then the team can prepare a plain-text report explaining the authorization impact and include the relevant observations.

Consider a dependency scan of a custom Airflow image. A scanner reports a known CVE in a package present in the image. The operator should first determine whether the package came from Apache Airflow itself, a provider, the base image, or a locally added dependency. The operator should then compare the finding with constraints, release guidance, SBOM data, and the deployed usage of that package. The repository policy makes clear that a bulk list of dependency scan results for Airflow or its Docker reference image is not, by itself, the kind of confidential vulnerability report the security address is intended to handle. Sources: .github/SECURITY.md

Consider a suspected Airflow flaw found during penetration testing. The team should avoid opening a public GitHub issue, because the policy warns against public disclosure through GitHub issues for security vulnerabilities. Instead, the report should be split so that each vulnerability has its own plain-text email. The description should focus on Airflow security impact: the trust boundary crossed, the expected protection, the actual behavior, the versions tested, and any safe reproduction information. Attachments should be avoided when the same information can be expressed clearly in text, because the policy prefers plain-text reports. Sources: .github/SECURITY.md

Compact Reference

Topic	Operational meaning	Repository-backed handling guidance
Audit logs	Evidence for user actions, task instance events, command-line events, and investigations described by the official security documentation.	Use the evidence to decide whether the matter is an operational incident, normal bug, or undisclosed vulnerability before escalating.
SBOM	Inventory of software components used to evaluate whether an installation or image may contain an affected package.	Treat inventories and scan results as input to assessment; do not send broad dependency lists to the security address as vulnerability reports.
Third-party dependency CVEs	Known advisories affecting packages that may appear in Airflow installations, providers, or images.	Evaluate constraints, image contents, and local customizations; use the confidential channel only when there is an undisclosed Airflow security issue.
Undisclosed Airflow vulnerability	A suspected flaw in Apache Airflow that requires private coordination.	Send one plain-text email per vulnerability to the Airflow security contact and explain the security impact.

Next Steps

Use this page as the escalation bridge between runtime evidence and project security process. For investigations inside an installation, start by reviewing the audit log and event log guidance in the official Airflow documentation. For dependency exposure, review SBOM and third-party dependency guidance, then compare findings with your actual deployment and image build. For a suspected undisclosed Airflow vulnerability, follow the repository policy: do not open a public GitHub issue, send a plain-text email for each vulnerability, and explain how the issue affects Airflow security. Sources: .github/SECURITY.md