docs(sbom): align with project's formal security policy

doc/SBOM.md and doc/CRA.md previously had no references to
wolfSSL's vulnerability disclosure process.  CRA Article 10
obliges manufacturers to handle and disclose vulnerabilities,
so a CRA-compliance doc that does not point integrators at the
disclosure path leaves the auditor with an incomplete handoff.

PR #10284 (already on master) published the project's formal
security policy at SECURITY-POLICY.md and a mandatory reporting
template at SECURITY-REPORT-TEMPLATE.md.  The policy explicitly
accommodates ecosystem-coordination embargoes for 'downstream
integrators, certification bodies, or equivalent' -- the exact
audience these CRA-compliance docs are written for.

doc/CRA.md: extends 'What to Give Your Auditor' with a
paragraph on the disclosure process, advisory feed, and the
embargo accommodation; lists SECURITY-POLICY.md and
SECURITY-REPORT-TEMPLATE.md under 'Further Reading'.

doc/SBOM.md: adds a closing paragraph to '5. Using wolfSSL's
artefacts in a product' pointing readers at SECURITY-POLICY.md
when a vulnerability is found in wolfSSL or any SBOM-listed
dependency.

This is congruent with the project's formal security policy
landed by #10284.

Author: MarkAtwood

doc/CRA.md

@@ -268,12 +268,28 @@ If you have a product-level SBOM that references wolfSSL via
 `ExternalDocumentRef` (SPDX) or a `bom` external reference (CycloneDX),
 include that product SBOM alongside the wolfSSL artefacts.
 
+CRA Article 10 also obliges manufacturers to handle and disclose
+vulnerabilities.  wolfSSL's vulnerability disclosure process is documented
+in [`SECURITY-POLICY.md`](../SECURITY-POLICY.md) at the repository root,
+with a mandatory reporting template at
+[`SECURITY-REPORT-TEMPLATE.md`](../SECURITY-REPORT-TEMPLATE.md).  Reports
+go to **support@wolfssl.com**; published advisories live at
+<https://www.wolfssl.com/docs/security-vulnerabilities/>.  The policy
+explicitly accommodates ecosystem-coordination embargoes for downstream
+integrators and certification bodies — point your auditor at this so
+they can verify the disclosure path before signing off.
+
 ## Further Reading
 
 ### wolfSSL documentation
 
 - `doc/SBOM.md` — unified reference covering SBOM generation, OmniBOR/Bomsh
   build provenance, combined workflow, output formats, and implementation notes
+- [`SECURITY-POLICY.md`](../SECURITY-POLICY.md) — vulnerability disclosure
+  policy, severity rubric, coordinated-disclosure practice, embargo
+  extensions for downstream integrators and certification bodies
+- [`SECURITY-REPORT-TEMPLATE.md`](../SECURITY-REPORT-TEMPLATE.md) —
+  mandatory template for vulnerability reports submitted to wolfSSL
 
 ### OpenSSF guidance
 

doc/SBOM.md

@@ -650,3 +650,11 @@ file.
 If you are shipping a product that includes wolfSSL and need to satisfy CRA
 obligations, see `doc/CRA.md` for guidance on integrating these artefacts
 into your product SBOM and what to provide to a conformity assessor.
+
+If a vulnerability is found in wolfSSL itself or in any dependency listed
+in the SBOM, see [`SECURITY-POLICY.md`](../SECURITY-POLICY.md) at the
+repository root for wolfSSL's disclosure process, severity rubric, and
+coordinated-disclosure practice.  Reports use
+[`SECURITY-REPORT-TEMPLATE.md`](../SECURITY-REPORT-TEMPLATE.md) and go to
+**support@wolfssl.com**; published advisories are at
+<https://www.wolfssl.com/docs/security-vulnerabilities/>.