Add Security Center 'How It Works' technical documentation #3766
Conversation
- Create new security-center-how-it-works.mdx page with technical details about CVE scanning, SBOM generation, and SecureBuild API integration - Enhance security-center-about.mdx with brief "How It Works" section that links to detailed page - Follows two-page architecture to separate value/features from technical implementation details Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
✅ Deploy Preview for replicated-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for replicated-docs-upgrade ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
replicated-ci
added
type::docs
Removed redundant explanation of the CVE scanning process and streamlined the content for clarity.
Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
Removed details about the release promotion process in Replicated Vendor Portal, including steps for extracting container image references and handling vulnerability scans.
Clarify the scanning process description in the documentation.
paigecalvert
left a comment
paigecalvert
left a comment
There was a problem hiding this comment.
@AmberAlston content looks good to me! I just went through this and suggested some edits that I think would allow everything to fit on the existing About page, rather than needing to add a new page. When you get a chance, take a look and let me know what you think. There was a fair bit that I was able to condense without losing meaning, as far as I could tell.
|
|
||
| The following describes the types of images that Replicated identifies for each release: | ||
|
|
||
| - **Container images in PodSpecs**: Any images defined in your Kubernetes manifests, such as Deployments, StatefulSets, DaemonSets, and so on. To build the list of container images for any Helm charts in the release, Replicated runs `helm template` using the chart's default values (or, using the Helm values that you provide in the Replicated HelmChart custom resource `builder` key). Then, Replicated parses the output of `helm template` to generate the list of images for the chart. For more information, see [Requirements](#requirements) on this page. |
There was a problem hiding this comment.
To build the list of container images for any Helm charts in the release, Replicated runs
helm templateusing the chart's default values (or, using the Helm values that you provide in the Replicated HelmChart custom resourcebuilderkey). Then, Replicated parses the output ofhelm templateto generate the list of images for the chart. For more information, see Requirements on this page.
Added a description of how this works for Helm charts, which felt useful since HelmChart is listed as a requirement to use Security Center. Could remove if it seems unnecessary
| The following describes the types of images that Replicated identifies for each release: | ||
|
|
||
| - **Container images in PodSpecs**: Any images defined in your Kubernetes manifests, such as Deployments, StatefulSets, DaemonSets, and so on. To build the list of container images for any Helm charts in the release, Replicated runs `helm template` using the chart's default values (or, using the Helm values that you provide in the Replicated HelmChart custom resource `builder` key). Then, Replicated parses the output of `helm template` to generate the list of images for the chart. For more information, see [Requirements](#requirements) on this page. | ||
| - **Additional images**: Any images listed in the Replicated Application custom resource [`additionalImages`](/reference/custom-resource-application#additionalimages) field. For example, applications packaged as Kubernetes Operators might need to include additional images that are not referenced until runtime. |
There was a problem hiding this comment.
additionalImagesfield. For example, applications packaged as Kubernetes Operators might need to include additional images that are not referenced until runtime.
added this xref and example
| 1. Security Center displays the results of the CVE scan in the Vendor Portal and Enterprise Portal: | ||
| - **Vendor Portal**: In the Vendor Portal, you can view a vulnerability overview with a severity breakdown, top risks, a complete image inventory with CVE counts, and detailed CVE information per image. | ||
| - **Enterprise Portal**: In the Enterprise Portal, your customers can view CVE reports showing known vulnerabilities, per-image details, and CVE reduction metrics when comparing versions. | ||
|
|
There was a problem hiding this comment.
^ did a pass on this process and the sbom process to remove passive voice. worth another pass to make sure I didn't choose an inaccurate subject
| @@ -0,0 +1,65 @@ | |||
| # How Security Center (Alpha) Works | |||
There was a problem hiding this comment.
Note: if you agree that the edits to the About topic cover the important points, I think we can remove this separate page
Co-Authored-By: Claude Sonnet 4.5 <[email protected]>
Preview link: https://deploy-preview-3766--replicated-docs-upgrade.netlify.app/vendor/security-center-about
Summary
This PR enhances the Security Center documentation by adding technical details about how CVE scanning and SBOM generation work, following a two-page architecture that separates high-level value from implementation details.
Changes
New page:
security-center-how-it-works.mdx- Comprehensive technical documentation covering:Enhanced existing page:
security-center-about.mdx- Added a brief "How It Works" section with link to detailed pageDocumentation Architecture
Uses a two-page approach to:
Why This Matters
The new technical content helps users understand:
🤖 Generated with Claude Code