Introduce changes for patch v1.0.1 - #8
Merged
Merged
Conversation
kkurzacz-intel
commented
Sep 22, 2026
kkurzacz-intel
commented
Contributor
- model-manager: deduplicate args by flag name in LLMInferenceService
- model-manager: add --label flag for deployments
- model-manager: undeploy --wait blocks until pods terminate
- nfd: label namespace with PSS profile when enforce_pss is true
- llm_services: provision the model-store PVC from the resolved storage backend
- ci: match all release branches in workflow triggers
Patch release on top of v1.0.0. - model-manager: deduplicate args by flag name in LLMInferenceService - model-manager: add --label flag for deployments - model-manager: undeploy --wait blocks until pods terminate - nfd: label namespace with PSS profile when enforce_pss is true - llm_services: provision the model-store PVC from the resolved storage backend Co-authored-by: jpiaseck <jakub.piasecki@intel.com> Co-authored-by: Ant Albersk <anna.alberska@intel.com> Co-authored-by: n-owi <mikolaj.nowicki@intel.com> Co-authored-by: sgurunat <gurunath.s@intel.com>
Trigger the security-scan workflows on release-[0-9]+.[0-9]+ branches (e.g. release-1.0.1), not just release-1.0, and add the same branch filter to pull_request events. Co-authored-by: Maciej Ramotowski <maciej.ramotowski@intel.com>
kkurzacz-intel
added a commit
that referenced
this pull request
Sep 24, 2026
* Merge pull request #2 from Mushtaq-BGA/release-1.0 Docs: rename to Intel® AI for Enterprise Inference + release doc fixes * docs: brand component badge as Intel AI for Enterprise Solutions (#3) Co-authored-by: release-bot <release-bot@users.noreply.github.com> * docs: add Intel® trademark to component badge (#4) Co-authored-by: release-bot <release-bot@users.noreply.github.com> * ci: add pinned security scanning workflows 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. * ci: eliminate false positives from the security scans 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. * ci: address review feedback on the scanning workflows 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. * ci: correct ansible-lint baseline counts in comment 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: raise ShellCheck threshold to error to suppress style warnings * Introduce changes for patch v1.0.1 (#8) * Release v1.0.1 Patch release on top of v1.0.0. - model-manager: deduplicate args by flag name in LLMInferenceService - model-manager: add --label flag for deployments - model-manager: undeploy --wait blocks until pods terminate - nfd: label namespace with PSS profile when enforce_pss is true - llm_services: provision the model-store PVC from the resolved storage backend Co-authored-by: jpiaseck <jakub.piasecki@intel.com> Co-authored-by: Ant Albersk <anna.alberska@intel.com> Co-authored-by: n-owi <mikolaj.nowicki@intel.com> Co-authored-by: sgurunat <gurunath.s@intel.com> * ci: match all release branches in workflow triggers Trigger the security-scan workflows on release-[0-9]+.[0-9]+ branches (e.g. release-1.0.1), not just release-1.0, and add the same branch filter to pull_request events. Co-authored-by: Maciej Ramotowski <maciej.ramotowski@intel.com> --------- Co-authored-by: jpiaseck <jakub.piasecki@intel.com> Co-authored-by: Ant Albersk <anna.alberska@intel.com> Co-authored-by: n-owi <mikolaj.nowicki@intel.com> Co-authored-by: sgurunat <gurunath.s@intel.com> Co-authored-by: Maciej Ramotowski <maciej.ramotowski@intel.com> --------- Co-authored-by: Mushtaq <mushtaq.ahmed@intel.com> Co-authored-by: release-bot <release-bot@users.noreply.github.com> Co-authored-by: sysadmin <sysadmin@localhost> Co-authored-by: jpiaseck <jakub.piasecki@intel.com> Co-authored-by: Ant Albersk <anna.alberska@intel.com> Co-authored-by: n-owi <mikolaj.nowicki@intel.com> Co-authored-by: sgurunat <gurunath.s@intel.com> Co-authored-by: Maciej Ramotowski <maciej.ramotowski@intel.com>
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
1 participant
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.