Sync main to release v1.0 - #7
Merged
Merged
Conversation
Docs: rename to Intel® AI for Enterprise Inference + release doc fixes
Co-authored-by: release-bot <release-bot@users.noreply.github.com>
Co-authored-by: release-bot <release-bot@users.noreply.github.com>
Add SARIF-publishing security scans for the release branch, following the pattern already used across the intel org (harden-runner + per-tool workflow files + OpenSSF Scorecard): - trivy vulnerabilities, secrets, misconfig, licenses (filesystem) - bandit Python security findings - checkov Kubernetes / Actions / secrets IaC checks - shellcheck shell script correctness and quoting - ansible-lint Ansible role and playbook hygiene - scorecard OpenSSF supply-chain posture rating Every action is pinned to a full commit SHA and every tool to an exact version, so a given commit always scans the same way and version bumps are explicit, reviewable diffs. ShellCheck is fetched from its upstream release and checksum-verified rather than installed via apt, whose version drifts with the runner image. Each scan was run locally against the tree before landing, and two were retuned as a result: - checkov drops the `helm` framework. Checkov renders charts into a random temp dir and reports paths relative to it, so all 50 (ai-solutions) / 40 (inference) findings pointed at files that do not exist in the repo -- unanchorable in the Security tab and re-reported as new every run. They were also entirely in vendored upstream charts. Trivy's misconfig scanner covers chart misconfiguration with correct paths. - ansible-lint skips style-only rule families, which accounted for 1158 of 1163 findings in ai-solutions and 496 of 502 in inference. name[casing] alone fired 350 times against the deliberate `role | action | desc` naming convention. Jobs are soft-fail for the initial rollout: findings surface under Security -> Code scanning instead of blocking the branch, so the existing backlog can be triaged before any check is made required. CodeQL is intentionally not added here - it already runs via code scanning default setup on both repositories.
Triage of every finding the scans produced, separating defects that cannot be
true from ones worth a maintainer's time. Every remaining finding was checked by
hand against the source and is real.
ShellCheck (33 -> 7)
Discovery now reads shebangs as well as *.sh suffixes: model_manager/model-
manager is the largest script in the tree at 1429 lines and a *.sh glob never
saw it.
Entry points are linted with -x so the helper scripts they source are
followed, plus a --source-path list -- the source statements are built from
"$MM_LIB/..." which ShellCheck cannot resolve unaided, and without it 7
globals that model_manager/lib/ does set and model-manager does read looked
unused.
The helper scripts under model_manager/lib/ are linted on their own.
ShellCheck sees one file at a time, so a global a helper sets for its caller
reads as unused: 26 of the 31 SC2034 hits were that. Disabling SC2034 for
those files was too blunt -- it also hid four globals that genuinely are
written and never read anywhere. Each hit is now checked individually and
suppressed only when another file demonstrably reads that variable, limited to
SHOUTY_CASE names of 3+ characters since a short lowercase name such as a
loop's `i` collides textually with unrelated files.
Kept, all verified by grepping the whole tree:
- config.sh:266 RUNTIME_DEVICE, parsed from the runtime JSON beside five
siblings that are all consumed, then never read -- cpu/gpu selection is
read and dropped.
- nri.sh:82,83 NRI_ADVANCED_MODE and NRI_HIDE_HT, both named in the
function's own "Sets:" header comment as outputs, neither consumed. The
Python side reads the MM_NRI_HIDE_HT environment variable, not this.
- nri.sh:241 NRI_TARGET_NODE, set beside NRI_POLICY_NAME which is used.
- helpers.sh:244 `local i` in a `for i in $(seq 1 24)` retry loop whose body
never uses it.
- helpers.sh:88, routing.sh:288 SC2155.
No file under model_manager/ was modified.
Bandit (0 -> 0)
Skips B404 (importing subprocess is not a defect) and B603, which fires on
the recommended argv-list form and cannot judge whether input is trusted.
shell=True and friends (B602/B604/B605/B609) stay enabled. Severity is
deliberately not filtered, since real tests such as B105 report LOW.
Trivy (17 -> 1)
`limit-severities-for-sarif` defaults to false, and unset it makes the action
drop --severity for the SARIF run alone -- the table reported 0 findings
while the uploaded SARIF carried all 17 at LOW/MEDIUM, every one below the
declared CRITICAL,HIGH threshold. Now split in two: CVEs, secrets and
licences at CRITICAL,HIGH with the limit applied; misconfiguration at every
severity, because Trivy rates nearly every Kubernetes check LOW or MEDIUM and
the same threshold would silence that scanner outright. Noise is controlled
by scope instead -- vendored charts/litellm-helm accounted for 16 of the 17
and is now skipped, matching the Checkov workflow.
Kept: KSV-0106 in roles/llm_services/files/runtimes/vllm-runtime.yaml, the
one finding in code this repo owns.
ansible-lint, Checkov
No false positives; the 4 ansible-lint findings stand.
Verified locally against the pinned tool versions, under `bash -e` as Actions
runs it. actionlint clean.
Three points from @mramotowski on #6, applied to both repos so the two stay identical. Drop the cross-repo reference in the ansible-lint comment. Justifying a skip list in one repo by citing another repo's finding count was noise; each file now carries only its own numbers, measured fresh. Note that `schedule` only fires from the default branch. Correct, and worth saying in the file rather than leaving as a trap: the weekly crons stay dormant until these workflows also land on `main`. The `push` and `pull_request` triggers are unaffected. Added to all four scheduled workflows. Scan once in Bandit instead of twice. The second invocation existed only to print something human-readable, and re-scanned the whole tree to do it. The summary is now rendered with `jq` from the SARIF the first scan already wrote, which also keeps the two outputs from ever disagreeing: Bandit: 1 finding(s) note B607 roles/postgresql/files/provision_db.py:34 Starting a process with a partial executable path No change to what any scan reports. Verified by extracting the generated Bandit step from the YAML and running it verbatim under `bash -e` in both repos -- 1 finding in ai-solutions, 0 in inference, and the summary degrades cleanly to "0 finding(s)". ansible-lint still reports 5 and 4. actionlint clean.
The counts in the skip-list rationale were measured locally, where ansible-lint silently skips schema validation because it cannot fetch the JSON schemas. Two schema[meta] findings therefore only appear in CI: roles/langfuse and roles/litellm are the only role metas declaring galaxy_info, and the schema requires 'author' whenever it is present. Baseline is 501 findings unfiltered and 6 substantive, not 499 and 4. name[casing] is unchanged at 350. ai-solutions is unaffected -- schema is an unskippable rule, so CI's filtered run would have surfaced any schema finding there, and it reported none. The two schema[meta] findings are left unfixed, consistent with every other genuine finding this PR reports rather than resolves.
ci: add pinned security scanning workflows
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This pull request introduces several new GitHub Actions workflows to enhance the project's security and code quality automation. It adds workflows for Ansible Lint, Bandit, Checkov, Scorecard, ShellCheck, and Trivy, each carefully pinned to specific tool and action versions for reproducibility and security. Additionally, it updates the project branding in the
README.mdto use the new "Intel® AI for Enterprise Inference" name.New security and code quality workflows:
.github/workflows/ansible-lint.ymlto lint Ansible roles and publish findings to GitHub Security (soft-fail for initial rollout)..github/workflows/bandit.ymlfor Python security scanning, including scheduled weekly runs and SARIF upload for findings..github/workflows/checkov.ymlfor Kubernetes, GitHub Actions, and secrets misconfiguration scanning, with findings uploaded to GitHub Security..github/workflows/scorecard.ymlto run OpenSSF Scorecard for supply-chain security posture, publishing results to GitHub Security..github/workflows/shellcheck.ymlfor shell script linting, including custom logic to accurately detect and analyze scripts and helpers..github/workflows/trivy.ymlfor vulnerability, secret, misconfiguration, and license scanning, with separate scans and SARIF uploads.Project branding update:
README.mdto use the new project name "Intel® AI for Enterprise Inference" and updated related badges and section headers accordingly. [1] [2]