Create flox-vs-containers-faq.mdx#22
Conversation
shift the docker contain FAQ from a google doc to a concept page we can utilise more easily for different purposes.
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
updating titles so we don't have 2 titles at top
|
Two things here — one mechanical, one structural — flagging together because the fix for the first depends on how we resolve the second. Mechanical: this new page isn't added to "concepts/secrets-management",
"concepts/flox-vs-containers",
"concepts/flox-vs-containers-faq"Structural (worth deciding first): we already have Suggestion: rather than a second standalone concept page, make this a dedicated FAQ — either its own FAQ page/section, or folded in as an FAQ section under the existing comparison page — so there's one canonical "Flox vs containers" destination and no near-duplicate. Once we pick the shape, the nav entry above follows from it. |
|
|
||
| <Accordion title="What about Docker's base image vulnerabilities?"> | ||
|
|
||
| This is a real consideration for some teams. Research from Chainguard and Sysdig has noted that popular base images often ship with significant numbers of CVEs, and that a substantial portion of running containers contain high-risk vulnerabilities. Docker users typically address this through image scanning, patching, and using minimal or hardened base images (like Alpine, distroless, or Chainguard images). Flox's approach is to include only the packages explicitly declared in the manifest, which can reduce the attack surface. |
There was a problem hiding this comment.
Worth nailing down before this ships: we cite Chainguard and Sysdig research here but link nothing. These docs get referenced externally (and increasingly cited by LLMs), so we should link the actual sources for the CVE / vulnerability stats — that way we can stand behind exactly what we're claiming. If we can't pin a specific source, let's soften to a general statement rather than attribute a precise finding to a named org. Uncited third-party stats are the kind of thing that gets challenged.
I intentionally didn't link it to the docs yet as that hadn't been 100% agreed as per the slack thread. If linked, I don't believe it should be added to the sidebar but to the existing container doc.
Correct, IF linked, my suggestion as per slack was to link it to the existing doc, not have it as an additional standalone doc. |
|
per the slack thread, 2 additional Qs to potentially add to the list:
|
2 participants
shift the docker contain FAQ from a google doc to a concept page we can utilise more easily for different purposes.