Repository navigation
Solutions Page - Compliance - Phase 1 - #4760
Draft
Chef-Pradyumn wants to merge 63 commits into
Draft
Chef-Pradyumn wants to merge 63 commits into
Chef-Pradyumn wants to merge 63 commits into
Conversation
- New content/solutions/_index.md: task/outcome-oriented Solutions homepage (card grid), with Compliance as the first fully-built solution and the remaining 7 areas from the Chef Docs Strategy & Information Architecture proposal marked 'Coming soon'. - New content/solutions/compliance/_index.md: Compliance solution overview page linking Chef InSpec, Chef Automate, Chef Infra Client, and Chef 360 into a single author -> scan -> visualize -> remediate -> orchestrate workflow, plus a benchmark coverage summary. - New content/solutions/compliance/<category>/_index.md (9 pages): category landing pages styled after /inspec/resource_packs/, each listing current audit/remediation coverage for that category, sourced from the Chef Compliance - Current Support Coverage catalog (Operating Systems, Desktop / Client, Databases, Cloud, Containers / Kubernetes, Web Servers, Applications / Middleware, Virtualization, Network / Infrastructure). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
…-span benchmark names Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
…r Chef Compliance Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
…view pages; enable sidebar on Solutions Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
✅ Deploy Preview for chef-web-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
…idebar Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Signed-off-by: Chef-Pradyumn <prabhu@progress.com>
Signed-off-by: Chef-Pradyumn <prabhu@progress.com>
Restructures the Compliance solution docs from a benchmark support matrix into a customer-outcome narrative, addressing review feedback that the content listed benchmarks without explaining what audit and remediation actually do or which real problems they solve. Overview page (content/solutions/compliance/_index.md): - Leads with the compliance problems Chef helps solve, not the catalog. - New reader journey: challenges -> how it works -> audit -> remediation -> scenarios -> coverage -> get started. - Adds a full "Compliance audit" section covering what is assessed, how a benchmark becomes runnable InSpec controls, the three ways to run an assessment, what results contain, how findings become a gap list, and how reports and waivers support evidence. - Adds a "Compliance remediation" section of equal depth covering what remediation content is, how it relates to benchmarks and controls, how it standardizes corrective action, how it pairs with audit, and what to check before using it. - Keeps audit and remediation distinct, and states explicitly that an audit version does not imply a matching remediation version. - Adds six real-world scenarios in problem -> approach -> outcome form. - Moves the coverage summary after the solution story and links out to the category pages. Category pages: - Regenerated from the validated internal catalog so the tables are derived from evidence rather than hand-maintained. - Each page now links back to the audit, remediation, and coverage-table explanations on the overview. - Drops the internal "OTHER" canonicalization prefix from five benchmark names. "OTHER" records the absence of a framework token in the source filename; it is a pipeline artifact, not a product fact. Affected pages note that no framework is shown rather than inferring one. - Excludes two internal/preview rows that are not customer-facing. Those records are unchanged in the internal catalog. Published coverage is now stated as 132 benchmarks (60 audit and remediation, 59 audit only, 13 remediation only) across 191 audit versions and 101 remediation versions. The previous 134 figure counted the two excluded internal rows, and contradicted the category index on the same page, which already summed to 132. All benchmark versions remain visible; no version set is reduced to a latest version. Every capability statement is grounded in existing Chef documentation. No new product capabilities, metrics, customer claims, or workflows are introduced. In particular, the Compliance Phase is described as audit-only, which is what its documentation supports. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Kuxhul <kushalj@progress.com>
- Replace RHEL mention in marketing copy with Ubuntu Linux - Add missing hyperlinks across the Compliance overview - Link to Chef InSpec install docs from "Write your own controls" - Simplify tautological/double-negative sentences; deduplicate repeated audit/remediation explanation - Add Chef Automate mention to "Evidence and reporting" - Replace all "estate" references with "fleet" for consistency - Reword all "rather than" phrasing for plainer language - Remove Inferred Current (dagger-marked) benchmark entries and their explanatory paragraph; recompute coverage totals and per-category counts across all affected pages - Remove the "no framework prefix" explanatory note (no longer broadly applicable) - Fix sidebar menu order to match the "Browse by category" table - Remove duplicate Chef Premium Content entitlement sentence - Introduce "The Chef Way" branding across headings and body copy Signed-off-by: Chef-Pradyumn <264104377+Chef-Pradyumn@users.noreply.github.com>
clintoncwolfe
self-requested a review
October 8, 2026 13:16
clintoncwolfe
previously approved these changes
Oct 8, 2026
clintoncwolfe
left a comment
clintoncwolfe
left a comment
Contributor
There was a problem hiding this comment.
I like this - as a partial take, need more product line obviously. I;d like the Docs teams input as well; it's a product-oriented direction, obviously with some marketing content.
Adds a shared capability page explaining how to build custom compliance checks with Chef InSpec, plus contextual resource-pack sections on the four domain pages where a pack is genuinely relevant: Cloud, Containers / Kubernetes, Databases, and Applications / Middleware. The change is strictly additive over the approved baseline (da44770): 228 insertions and no deletions. The nine domain pages keep their URLs, front matter, benchmark tables, published figures, and sidebar order unchanged, including the removal of Inferred Current entries and the recomputed coverage totals. The domain page changes are made through the local catalog generator, which was reconciled to reproduce the approved pages byte-for-byte so regeneration can't restore the superseded tables. The new page states explicitly that a resource pack is not a benchmark and that pack availability does not indicate benchmark coverage. No sentence on a domain page contradicts the benchmark table above it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Kushal J <kushalj@progress.com>
…nd installation Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Leadership feedback on PR chef#4760 was that the Compliance solution pages read as marketing rather than as solutions, and don't explain how to do anything. This addresses that without changing the approved benchmark catalog. Add a task-oriented walkthrough, "Audit SSH configuration across a Linux fleet", covering profile creation, control authoring, validation, execution, reading results and exit codes, fix-and-reassess, and waiving an accepted exception. Commands and CLI output were captured from real runs rather than written from memory. Remote SSH, cloud and Kubernetes commands come from the official CLI reference and are shown without fabricated output. Rework the custom checks page from an inventory into practical guidance, documenting the three resource pack distribution patterns with a worked example for each. Rewrite the six compliance scenarios so each ends in concrete linked steps instead of an aspirational outcome, and point two of them at specific steps of the walkthrough. Note plainly where no dedicated guide exists yet. Replace a promotional paragraph in "Getting Chef Compliance content" with actionable guidance, preserving its intent. The nine domain pages, benchmark tables, published figures, domain taxonomy, URLs and navigation weights are unchanged. Catalog regeneration produces no diff. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The cspell check failed on the Compliance overview. "walkthrough" is only present in @cspell/dict-software-terms, and the version bundled with cspell-action v2.1.1 doesn't include it, so CI flagged five occurrences that a locally installed newer dictionary accepted. Use "guide" instead, which is in the base en_US dictionary and so doesn't depend on the software-terms dictionary version. Link targets and anchors are unchanged. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Hands-on guide using the AWS resource pack: install/verify Chef InSpec, set up AWS credentials, write controls against S3, IAM, and security group resources, run the assessment, read results, fix and reassess, waive an accepted exception, and schedule recurring AWS scan jobs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
- Collapse the five 'Compliance challenges' subsections into one bulleted list instead of a prose essay. - Shorten the audit mechanics subsections (benchmark-to-profile, assessment results, evidence/reporting) that duplicated detail already documented at the Compliance Phase, scan jobs, and compliance reporting pages; link out instead of re-explaining. - Link the SSH baseline guide from where profiles are introduced. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Replace the opening pitch-style intro and 'Compliance challenges Chef helps solve' agitate section with a concise intro, a direct problem statement, and a 'What this solution implements' section that routes straight to the SSH baseline and AWS foundations guides plus the scenarios list. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Remove 'The Chef Way of Compliance' 6-step loop, now redundant with the problem statement and 'What this solution implements' section at the top of the page. Replace the 3-bullet 'Chef Way of compliance remediation' benefit pitch with one factual paragraph covering the same facts (consistent application, cookbook workflow, idempotent convergence). Drop a trailing sentence that just re-sold the numbered steps above it. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Replace generic/awkward headings with ones that name the actual content: 'The problem' -> 'Why compliance drifts between audits', 'How a benchmark becomes something you can run' -> 'From benchmark to runnable profile', 'What remediation content is' -> 'Remediation content', 'How remediation content behaves' -> 'How remediation content runs', 'How audit and remediation work together' -> 'The audit, remediate, reassess cycle'. Update the matching internal anchor link. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Merge or cut subsections whose content is already documented in detail elsewhere: 'From benchmark to runnable profile' (duplicates /inspec/profiles/), 'What an assessment gives you' and 'Evidence and reporting' (both duplicate /automate/reports/, merged into one 'Results and evidence' section), 'Remediation content' and 'How remediation content runs' (duplicate /client/.../cookbooks/ and general Chef Infra Client convergence docs, folded into the section intro), and 'The audit, remediate, reassess cycle' (duplicated the cycle already stated in 'What this solution implements'). Keep subsections that add information not found elsewhere: 'What gets assessed', 'How you run an assessment' (comparison table), 'How remediation relates to benchmarks and controls' (explains the audit/remediation version independence), and 'Before you use remediation content' (checklist). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Signed-off-by: Pradyumn Prabhu <pradyumn.prabhu@progress.com>
Fix the IAM control, which used three identifiers the AWS resource pack doesn't document: where(attached:) instead of only_attached, entry_names instead of policy_names, and an allow_actions property that doesn't exist on aws_iam_policy. Use have_statement, which the pack documents for this check, and note that it matches literal values without expanding wildcards. Add the vendoring step. inspec check and inspec exec both fail on an unfetched dependency, so the guide couldn't be followed end to end. Correct the generator output and inspec.yml guidance, which omitted inputs.yml and showed supports as platform-name rather than platform, and keep depends and supports in the edited inspec.yml so copying the example doesn't break the profile. Replace the inspec detect claim that a failure indicates a credentials problem. On InSpec 5.24.7 the command returns platform details with no credentials set, so it confirms the transport loaded and nothing more. Fold in the material from the S3 baseline draft: per-resource IAM permissions, exit codes, the Automate AWS API node manager path, the be_public object-ACL limitation, and a note recording which output was executed and which is illustrative. Add an extension section covering S3 default encryption and secure transport on the same profile. Remove the unresolved screenshot placeholder from the reporting note. Link the guide from the Compliance overview as a cloud scenario and from the Cloud domain page through the page generator. Signed-off-by: Kushal J <kushalj@progress.com>
Adopt meaningful control IDs on both pages, replacing ssh-01/02/03 and aws-01..05 with names that state each control's intent, and expand the naming guidance to explain kebab-case intent, the optional leading number, and why identifiers must stay stable. SSH baseline: - Re-capture every command and output block against an Amazon Linux 2023 host on Chef InSpec 7.3.4 rather than editing the previous output. - Add an InSpec Parallel section after the multi-host loop. - Expand the exit code table with the codes defined in Chef InSpec 7. - Explain in Step 7 how renumbering misdirects waivers, in both directions, and add the missing --sudo flag to the Step 6 re-run. Without it the controls skip with "Can't read file" and the run exits 101, which reads as a pass. AWS Foundations: - Move the page to Chef InSpec 7.3.4 and re-capture the generator, vendoring, check, detect, and missing-credential output on it. - Set inspec_version in the profile, since the generated constraint stops the profile from running on Chef InSpec 7. The AWS resource layer still comes from the community inspec-aws pack and is unchanged here. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
3 of 4 tasks
2 of 4 tasks
Restructure Premium Content coverage from a single flat benchmark table into per-platform pages, as requested in the docs review. Each page describes the platform, the supported benchmark versions, the profiles that ship, what you can audit, harden, and detect drift on, and what remediation is available. AlmaLinux and Windows Server are the first two, chosen to establish the page shape across both a simple and a complex platform before the remaining families follow. Windows Server carries both CIS and STIG content and needs separate version tables and naming patterns for each, which AlmaLinux does not. Profiles are published as a naming pattern plus the values each part can take, rather than an exhaustive list. Windows Server ships more than 300 profiles, so a full listing would be unreadable and would go stale; the pattern lets a reader derive the profile name they need. The CIS Windows platform token is windows<version>, not the benchmark title, and the STIG content is organized by DISA Mission Assurance Category rather than by profile level. Both are documented here for the first time. Coverage data comes from the published catalog, which is already validated, rather than from the evidence database, which still contains unreviewed rows for this family. Also document the content build suffix on the Premium Content overview. Coverage tables list the benchmark version, but delivered content carries a build number such as 2.0.0-3, which increments when Chef republishes a corrected build of the same benchmark version. Build numbers are deliberately kept out of the per-platform tables because they change independently of the benchmark. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Continue the Premium Content per-platform restructure with the three highest-traffic operating system families. Ubuntu and Red Hat Enterprise Linux carry both CIS and STIG coverage, so they follow the Windows Server page shape; Debian is CIS only and follows the AlmaLinux shape. Coverage tables are taken from the published manifest-derived catalog. Profile naming is family-specific and documented as a pattern plus axis values rather than an exhaustive list, including the exceptions: - Ubuntu 12.04 and 14.04 ship level only, with no server or workstation scope; the CIS token carries a trailing "lts" and the STIG token a "canonical" prefix. - Red Hat Enterprise Linux 5 ships level only; CIS uses the short "rhel" token while STIG uses "redhatenterpriselinux", and disableslowrules ships for RHEL 9 only. - Debian uses the "debianlinux" token, not "debian". Reorder the operating system menu weights alphabetically now that more families are present, moving Windows Server to the end of the section. Allowlist the three new profile name tokens in cspell.yaml, matching the existing Premium Content token entries. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
MD049 is configured for underscore emphasis, so the single asterisk emphasis introduced in the Premium Content overview failed markdownlint in CI. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Nov 6, 2026
The Windows Server coverage tables didn't match the published catalog. Verifying every per-platform table row against the catalog found seven defects on this page and none elsewhere: - A STIG Microsoft Windows Server 2012 row was published, but that benchmark has no current coverage in the catalog. Remove it. - The Windows Server 2016 and 2019 STIGs listed audit versions. Both are remediation only, so the audit column is empty and the coverage label changes accordingly. - The Windows Server 2019 CIS row listed audit v1.1.0 and v1.2.1, which are remediation versions, not audit versions. - The Windows Server 2016, 2019, and 2022 CIS rows were missing remediation versions. - The Windows Server 2025 CIS row was marked audit only. It has matching remediation at v1.0.0 and v2.1.0. Overstating coverage is the more serious direction of these errors, because a reader planning an audit rollout against the Windows Server 2016 STIG would find no audit content. Update the prose that depended on the incorrect tables. The STIG profile example used Windows Server 2016 at v2.1.0, which names an audit profile that isn't published; use Windows Server 2019 at v2.2.0 instead. Replace the note about Windows Server 2012 STIG role tokens, which no longer applies, with a statement of which STIGs carry audit content. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…ky Linux, and SLES Continue the per-platform restructure with five more operating system families. Oracle Linux carries both CIS and STIG coverage and follows the Red Hat Enterprise Linux page shape; the other four are CIS only and follow the Debian shape. Ten of the thirteen families now have pages. Coverage comes from the published catalog. Profile naming is documented as a pattern plus axis values, except where a pattern would mislead. The scope component turns out to depend on the benchmark version rather than the platform, which earlier pages didn't need to express: - Oracle Linux 7 ships level only at v1.1.0, but gains server and workstation scope at v3.1.1. - CentOS Linux 6 and 7 ship level only at v1.1.0, with scope from v2.0.2 and v2.2.0 onward. - SUSE Linux Enterprise Server 11 and 12 ship level only at v1.1.0 and v1.0.0, with scope from v3.1.0 onward. Each page states the exception so a reader doesn't construct a profile name that was never published. Amazon Linux has no workable single pattern: Amazon Linux 1 and 2 ship level only, Amazon Linux 2023 ships a server scope with no workstation variant, and the Amazon Linux 1 platform token embeds a release date range rather than a version. The eight profile names are listed in full instead. Oracle Linux uses the same oraclelinux token for both CIS and STIG profiles. This is worth stating plainly because Red Hat Enterprise Linux uses a short token for CIS and a long one for STIG, so readers arriving from that page expect a second token that doesn't exist here. Content present in the evidence database but absent from the catalog is excluded: Rocky Linux 9, Oracle Linux 6, the Oracle Linux 7 STIG, and the SUSE Linux Enterprise Server STIGs, which sit in the unsupported tree. Allowlist the four new profile name tokens in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The nine generated category pages were still built from a superseded catalog and had drifted from the per-platform pages. The operating systems page listed 66 benchmarks where the catalog has 61, including five with no current coverage: CIS Debian Linux 10, CIS Oracle Solaris 11.4, CIS Rocky Linux 9, STIG Microsoft Windows Server 2012, and STIG Red Hat Enterprise Linux 10. The generator had been refusing to run because its row-count guards still expected the old catalog, so the drift was contained rather than silently published. Update both guards to the current 118 rows. The publication total now equals the catalog total, because the manifest-derived catalog carries no Inferred Current remediation versions and no non-product domain. Both filters are kept so a future catalog that reintroduces either is still handled. The generator also reproduced two edits that had been applied to its output by hand, which would have reverted them: - The custom compliance checks link had been corrected to its current URL on all nine pages. - The operating systems page had gained a platform index linking to the per-platform pages. Teach the generator both. The platform index derives its Frameworks column from the catalog rows each platform matches, rather than restating them, so a platform that gains or loses a framework stays accurate. Platforms without a page yet are skipped so no link 404s, and the generator refuses to run if a platform page exists that it doesn't know about, which is how this drift started. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Complete the operating systems domain. All thirteen families now have a page, so the category index no longer says platform pages are in progress. These three are the first families whose benchmarks are audit only at every version, and the first with no server or workstation scope on any profile. Both are stated explicitly on each page, because a reader arriving from any of the ten Linux pages has reason to expect otherwise. The Harden and Remediation sections say plainly that no cookbooks are published for these platforms and point to the custom compliance checks guide, rather than describing remediation content that doesn't exist. IBM AIX spells its platform token three different ways across four benchmarks: aix-5.3-6.1 for AIX 5.3, ibmaix7 for AIX 7, and aix7.1 and aix7.2 for the point releases. No pattern survives that, so all fourteen profile names are listed in full, as on the Amazon Linux page. The 5.3 benchmark covers AIX 5.3 and 6.1 together, which is where its range token comes from. Oracle Solaris keeps the dot in its version token, as in oraclesolaris11.2. Its benchmark versions also run well ahead of the release numbering, with Solaris 10 at v5.2.0 and Solaris 11 at v1.1.0, so the page warns against reading a higher benchmark version as newer content. HP-UX has one benchmark and two profiles. Its token is hp-ux11i, the only platform token in this section carrying a hyphen, so the page warns against flattening it to hpux11i. Oracle Solaris 11.4 is excluded. Profiles for it exist in the content repo but were never released and it has no catalog row. Allowlist the two new profile name tokens in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Regenerate the category pages now that HP-UX, IBM AIX, and Oracle Solaris have pages. The platform index lists all thirteen families, and the generator drops the "remaining platforms are in progress" sentence on its own because every platform it knows about now has a page on disk. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
…and PostgreSQL Start the Databases domain with the three products that have more than one benchmark version: Microsoft SQL Server, Oracle Database, and PostgreSQL (13 of the domain's 17 catalog rows). MariaDB, MongoDB, Oracle MySQL, and MarkLogic Server stay in the category table only, since each is a single benchmark with nothing more to document on a dedicated page. SQL Server's naming has a version- and scope-dependent trap: Level 2 exists only from the second benchmark version for 2016 and 2017, and only for the Database Engine scope, not AWS RDS. It isn't a scope-always, level-always platform like the OS pages. Oracle Database has no stable pattern at all. The profile shape changes at every major version: a six-profile host-OS by auditing-mode grid through 12c, 18c, and 19c v1.0.0, collapsing to two profiles at 19c v2.0.0 when the auditing-mode axis drops, then three profiles at 23ai when the host-OS split returns with named operating systems. Profiles are listed per version rather than forced into one pattern, the same treatment IBM AIX got. Oracle Database also has no Level 2 at any version, unlike every other platform documented so far. PostgreSQL combines CIS and STIG on one page, the second database platform to need that after Oracle Linux. CIS PostgreSQL 10 is remediation only: profile names matching the pattern exist in the content repository but were never released, so the page says plainly that no audit content exists for that version rather than let the pattern imply otherwise. STIG PostgreSQL 9.x carries a bare v2 version token with no dotted scheme, and covers the 9.x line as one generation rather than a specific point release. Allowlist the new profile name tokens in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Link the three new database platform pages from the category index Regenerate the category pages now that Microsoft SQL Server, Oracle Database, and PostgreSQL have dedicated pages. The Databases page gains a platform index linking all three; because every entry registered for this domain now has a page, the generator doesn't add an "in progress" note, which is correct since the remaining four products are staying in the category table by design, not awaiting a page. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Complete the Databases domain's platform pages by covering the three remaining products with real, documentable profile naming: MariaDB, MongoDB, and Oracle MySQL. MarkLogic Server stays in the category table only, since the catalog has no stated version or profile data for it to document on a dedicated page. MariaDB is the simplest page in the domain: one release (10.6), one benchmark version, two levels times two scopes (mariadbrdbms, mariadbrdbmsonlinux), audit only, no traps. MongoDB covers two benchmark versions (v1.0.0, v1.1.0) released against a single MongoDB release (3.6), with full audit and remediation alignment at both versions and a single scope token. It is written plainly, without manufacturing a naming complexity that is not present in the evidence. Oracle MySQL documents only CIS Oracle MySQL 5.7, Community Edition, the sole row in the supported benchmark catalog for this product. Internal naming evidence for an Oracle MySQL Enterprise Edition 8.4 profile set exists in the source repositories but isn't in the supported catalog, so it is deliberately excluded from this page. Allowlist the new profile name tokens in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Link MariaDB, MongoDB, and Oracle MySQL from the Databases index Regenerate the category page now that MariaDB, MongoDB, and Oracle MySQL have dedicated pages. All six platforms with distinct naming to document are now linked from the Databases index; MarkLogic Server remains in the category table by design, not awaiting a page. Signed-off-by: Kushal J <kushalj@progress.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Complete the Desktop / Client domain with platform pages for its two products, covering all 20 catalog rows. Apple macOS has two profiles for each benchmark version, one for each level. The platform token varies by release: appleosx through 10.12, applemacos from 10.13, and applemacos13.0ventura for 13.0. Windows documents CIS and STIG profiles for Windows 10 and 11. The CIS variants differ by release, so the page lists them in a table: 21H1 ships without the two optional add-ons, and Windows 11 ships five variants. The Windows 10 STIG is remediation only, so the page publishes no audit profile names for it. Regenerate the category page to link both pages, and allowlist the new profile name tokens in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for Apache Tomcat, the only product in the Applications / Middleware domain with more than one catalog version. IBM WebSphere Liberty and Microsoft Exchange Server 2016 each have one row, so they stay in the category table. Tomcat profile names don't follow a single pattern, so the page lists them for each benchmark. The 5.5 profile name covers 5.5 and 6.0, Tomcat 8 ships one profile with no levels, and Tomcat 10.1 ships with the apachetomcat10 token. Regenerate the category page to link the new page, and allowlist the new profile name token in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for IBM WebSphere Liberty, which has one catalog row at benchmark v1.0.0. It ships two audit profiles, one for each level, and has no remediation content. Regenerate the category page to link the new page, and allowlist the new tokens in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for Microsoft IIS covering its CIS and STIG benchmarks. CIS IIS 10 ships two profiles with matching remediation at v1.1.1. The IIS 10.0 STIG is audit only and ships nine profiles versioned as v2, without the cationly and disableslowrules variants. Regenerate the category page to link the new page, and allowlist the new profile name token in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for Apache HTTP Server 2.2 and 2.4. The two releases use different platform tokens, so the page gives a pattern for each. Correct the CIS Apache HTTP Server 2.2 row on the category page. It listed audit v0.1.0 and Remediation Ahead because the catalog read the packaging number in cis-apache-http-server2_2-level1-v3_6_0-0.1.0-1 as the benchmark version. Audit and remediation both ship at v3.6.0. Headline figures don't change. Allowlist the new profile name token in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for VMware ESXi. Its audit content ships as scan cookbooks rather than standalone Chef InSpec profiles, so the page describes running them from a Chef Infra Client node against vCenter Server, the vmware_scan_config.yaml settings, and how reports reach Chef Automate. The ESXi 7.0 cookbook also scans distributed networks. The ESXi 8.0 cookbook scans hosts and VMs only. Regenerate the category page to link the new page, and allowlist the new tokens in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Add platform pages for the CIS Azure Foundations and CIS Microsoft 365 benchmarks. Azure covers audit v1.0.0 and v1.1.0 with remediation at v1.1.0. Benchmark v1.0.0 ships one profile with no levels. Some remediation controls need values set as environment variables. Microsoft 365 audit runs from a Windows host with PowerShell modules, an account with the right roles, and a set of inputs. Audit is at v1.4.0 and remediation at v1.0.0, and the page lists the known limitations of each. Regenerate the category page to link both pages, and allowlist the new tokens in cspell.yaml, along with common terms that rely on specialist dictionaries. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for the CIS AWS Foundations benchmark, which is audit only at v1.0.0. It ships two profiles, one for each level, without a v before the version in their names. Link the custom profile guide and make clear that it's separate from this benchmark, and regenerate the category page to link the new page. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for Cisco IOS 12 and 15, which are audit only at v4.0.0 with two profiles for each release, one for each level. Regenerate the category page to link the new page, and allowlist the new profile name token in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Add a platform page for the CIS Docker benchmark, which is audit only at v2.1.0 and ships as one profile. Regenerate the category page to link the new page. Also correct its resource pack introduction, which said that Chef doesn't publish prebuilt audit content for the benchmarks listed above it, although CIS Docker has audit content. Signed-off-by: Kushal J <kushalj@progress.com>
Change the category's published name on its own page, in the menu, on the overview page, and on the Docker page. Docker is the only benchmark in this category. The URL stays the same, so existing links continue to work. Signed-off-by: Kushal J <kushalj@progress.com>
Replace the product descriptions at the start of each platform page with what the benchmarks define and what Chef provides for them. Add a "What the benchmarks check" section to all 31 platform pages. Each one summarizes the requirement areas of a named benchmark version, based on that benchmark's Chef InSpec control titles. The Docker summary uses public descriptions of the CIS Docker Benchmark because its source isn't available in the content repository. Allowlist the new technical terms in cspell.yaml. Signed-off-by: Kushal J <kushalj@progress.com>
Lead with what Premium Content is and a platform index that links to every platform page, followed by coverage, usage steps, reference material, and access details. Add how licensed users get profiles and cookbooks, through the monthly delivery email and Chef Automate. Correct the coverage figures, which still showed the earlier catalog, to 118 benchmarks: 58 audit and remediation, 54 audit only, and 6 remediation only, with 164 audit versions and 87 remediation versions. Signed-off-by: Kushal J <kushalj@progress.com>
Lead the page with the Chef way: requirements as code, then a repeatable path of audit, correct, confirm, and repeat, followed by a table that points readers to the right guide or platform page. Shorten the page from about 2,900 to about 1,500 words by merging the introductory and getting-started sections, and give all seven scenarios the same problem-and-steps format. Correct how content reaches users. The page now says that licensed users get profiles and cookbooks through a monthly delivery email and Chef Automate, and links to the Premium Content overview for details, in place of the earlier single tar file description. Link the Windows scenario to the new platform pages. Keep the URL, front matter, and heading anchors that other pages link to. Signed-off-by: Kushal J <kushalj@progress.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
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.
Summary
Introduces a new Solutions section to chef-web-docs, organized around customer outcomes rather than individual products, starting with a Chef Compliance solution.
Structure
Overview -> Solutions -> Overview(/solutions/) - landing page for all solutions (card grid), with Chef Compliance live and 7 other solution areas marked "Coming soon".Overview -> Solutions -> Compliance -> Overview(/solutions/compliance/) - Chef Compliance overview: workflow, common scenarios, and a benchmark coverage catalog.Overview -> Solutions -> Compliance -> {9 categories}- benchmark coverage tables (Operating Systems, Desktop/Client, Databases, Cloud, Containers/Kubernetes, Web Servers, Applications/Middleware, Virtualization, Network/Infrastructure), sourced from the internal "Chef Compliance - Current Support Coverage" catalog.This is a draft to gather early feedback on IA/copy before final review.