Product Security Toolkit: SBOMs, Vulnerability Disclosure, and Recall Decisions

Summary. The working documents of a product security function, annotated.

Template 1 — Vulnerability disclosure policy

Reporting a vulnerability. We welcome reports from security researchers. Send reports to security@[company].com. We monitor this address and it does not route through general support.

What to include. The affected product and version; a description of the issue; steps to reproduce; the impact you believe it has; and how you would like to be credited.

What you can expect.

• Acknowledgment within 2 business days.
• An initial assessment and severity within 5 business days.
• Status updates at least every 14 days until resolution.
• Credit in our advisory, if you wish.

Coordinated disclosure. We ask that you allow us 90 days before public disclosure. If remediation requires longer, we will explain why and propose a date. If we cannot fix an issue, we will tell you and discuss disclosure.

Safe harbor. If you conduct security research in good faith and within the scope below, we will not initiate or support legal action against you, and we consider your research authorized. We cannot waive claims by third parties or by government authorities.

In scope: [products and services]. Testing on devices and accounts you own or are authorized to test.

Out of scope: accessing, modifying, or exfiltrating data belonging to others; denial of service; physical attacks; social engineering of our personnel; testing on devices you do not own; and any activity that degrades service for others.

Bounty. [State terms, or: We do not currently offer a bounty.]

Publish at a discoverable URL and in /.well-known/security.txt.

The two provisions that matter most: an address that bypasses general support, and safe harbor language. Without the first, reports sit while clocks run. Without the second, researchers publish rather than report.

Template 2 — Triage worksheet

VULNERABILITY TRIAGE                   ID: ______  RECEIVED: ______

1. SOURCE
   [ ] Researcher  [ ] Customer  [ ] Internal  [ ] Coordinating body
   [ ] Public disclosure already made
   Reporter contact: ______      Acknowledged on: ______

2. AFFECTED
   Products / versions / configurations:
   Units in field (est.): ______

3. TECHNICAL
   Reproduced?  Y/N  By: ______  Date: ______
   Attack prerequisites: [ ] Network position  [ ] Authentication
                         [ ] Physical access   [ ] Specific config
   Impact: [ ] Data  [ ] Device control  [ ] SAFETY FUNCTION
   Actively exploited?  Y/N  Evidence: ______

4. SEVERITY
   Score: ______   Vector: ______   Assigned by: ______

5. *** PRODUCT SAFETY ANALYSIS *** (mandatory, same day)
   Does this defeat or degrade a safety function?        Y/N
   Could it create a substantial product hazard?         Y/N
   Could it create an unreasonable risk of serious
   injury or death?                                      Y/N
   -> If ANY yes: 15 U.S.C. 2064 reporting clock IS RUNNING.
      Escalate to [named person] TODAY.
   Analysis by: ______   Date: ______

6. OTHER REPORTING TRIGGERS
   [ ] Personal data exposed -> privacy notification analysis
   [ ] Medical device -> correction/removal analysis
   [ ] Vehicle -> safety defect analysis
   [ ] Public company materiality -> securities analysis
   [ ] Non-US markets -> see reporting map

7. REMEDIATION
   Owner: ______  Target date: ______  Release vehicle: ______
   Workaround available?  ______

8. DISCLOSURE
   Proposed date: ______  Agreed with reporter?  Y/N

9. CUSTOMER NOTIFICATION
   Required?  Y/N   Channel(s): ______   Date: ______

Section 5 is the reason this document exists. Security teams reliably classify a vulnerability as a security matter and never ask the product safety question, and the reporting clock runs from when the company had the information.

Template 3 — Product safety reporting decision aid

One page. Written for an engineer, not a lawyer. Keep it with the triage worksheet.

DO WE HAVE TO REPORT THIS?

THE STANDARD (15 U.S.C. 2064; 16 C.F.R. Part 1115)
  You must report when you obtain information that REASONABLY
  SUPPORTS THE CONCLUSION that the product:
    (a) fails to comply with a safety rule; or
    (b) contains a DEFECT that COULD create a substantial
        product hazard; or
    (c) creates an UNREASONABLE RISK of serious injury or death.

WHAT THIS MEANS IN PRACTICE
  - You do NOT need certainty. "Reasonably supports the
    conclusion" is a low bar.
  - You do NOT get to finish the investigation first. The
    regulation allows a short period to investigate, not months.
  - The clock starts when the COMPANY has the information — not
    when it reaches legal, and not when engineering confirms it.
  - A SOFTWARE defect is a defect. Firmware counts.
  - "Could create" is not "has created." No injury is required.

QUESTIONS THAT USUALLY MEAN YES
  - Can an attacker disable a safety function?
  - Can an attacker cause the device to operate unsafely?
  - Does the flaw prevent the product from doing the safety job
    it was sold to do?
  - Would a customer be surprised to learn the device can be
    made to fail this way?

IF IN DOUBT
  Escalate today to [named person]. Reporting when not required
  is not a violation. Failing to report when required is —
  15 U.S.C. 2068 and 2069.

Template 4 — Severity and remediation matrix

Deferral record — required for every item exceeding target:

Item: ____ · Severity: ____ · Target date: ____ · Actual/projected: ____ Reason for deferral: ____ Interim mitigation offered to customers: ____ Approved by: ____ · Date: ____

This record is the exhibit. A documented decision with reasoning is defensible; a backlog item that sat for eighteen months with no explanation is not.

Template 5 — Software bill of materials requirements

The practical test: when a widely used component is found vulnerable, how long does it take to answer "are we affected?" Hours is the target. Weeks means the inventory is not real.

Communicating "not affected" well: state which products contain the component, which are exploitable in their shipped configuration, and why the others are not. A bare "we are not affected" invites the follow-up question and reads as evasion.

Template 6 — Security advisory

SECURITY ADVISORY [ID]                      PUBLISHED: [date]

AFFECTED PRODUCTS AND VERSIONS
  Affected:      [precise list]
  NOT affected:  [precise list]

SUMMARY
  [One paragraph an IT manager can act on.]

IMPACT
  [What an attacker could do. Plainly. Do not minimize here.]

PREREQUISITES FOR EXPLOITATION
  [Network position, authentication, physical access, config.
   Honest scoping belongs HERE, not in the impact section.]

SEVERITY
  Score: ____   Vector: ____

REMEDIATION
  Fixed in version ____ . How to obtain and verify:

WORKAROUNDS
  [For customers who cannot update immediately.]

TIMELINE
  Reported: ____  Acknowledged: ____  Fixed: ____  Published: ____

CREDIT
  [Reporter name, if they wish.]

CONTACT
  security@[company].com

Legal review before publication, for three things: does it contradict any prior representation about the product's security; is it consistent with any regulatory filing about the same defect; and is the severity description defensible against the internal assessment?

Template 7 — Support period statement

Publish on the product page, the packaging, the documentation, and in-product where there is a screen.

Security update commitment. [Company] will provide security updates for [Product] for [N] years from the date this product was last offered for sale, currently through [date].

What this covers. Updates addressing security vulnerabilities we identify or that are reported to us, delivered through the product's automatic update mechanism.

What happens at the end. We will notify registered owners and publish notice 12 months, 6 months, 90 days, and 30 days before the end date. After that date, [state one: the product will continue to function without further security updates / cloud services will end on [date] and the product will operate in local-only mode / describe].

Registering your product at [link] ensures you receive these notifications.

Confirm supplier support periods match or exceed this before committing. A component whose supplier stops supporting it in year three of your seven-year commitment is a problem created at selection time.

Template 8 — End-of-support notification

Subject: Important: security updates for [Product] end on [date]

We are writing because you own a [Product]. Security updates for this product will end on [date], [N] months from now.

What this means. After [date], we will no longer release updates addressing newly discovered security vulnerabilities. The product will [continue to function normally / operate in local-only mode / describe].

What we recommend. [Specific steps: update to the current version now; consider network segmentation; consider upgrading to [current model], for which we are offering [trade-in / discount] through [date].]

Why products reach end of support. [Brief, honest explanation.]

Questions: [contact]. Full details: [link].

Send at 12 months, 6 months, 90 days, and 30 days, through every channel: email to registered owners, in-product notification, and a published advisory.

Template 9 — Supplier security terms

Component inventory. Supplier will deliver, with each release, a complete machine-readable inventory of all components in the Deliverables, including transitive dependencies, with versions, suppliers, and licenses.

Security requirements. The Deliverables will meet the requirements in Exhibit [ ], including: no shared default credentials; support for authenticated updates; encryption of sensitive data; and disabling of debug interfaces in production builds.

Vulnerability notification. Supplier will notify Customer within [3] business days of becoming aware of any vulnerability affecting the Deliverables, and within [24] hours where the vulnerability is being actively exploited.

Remediation. Supplier will remediate vulnerabilities on the following timelines: critical within [7] days; high within [30] days; medium within [90] days.

Support period. Supplier will provide security updates for the Deliverables for not less than [N] years from [last delivery / Customer's product end-of-sale], matching or exceeding Customer's published commitment to its own customers.

Escrow and step-in. [Source escrow with release conditions, or an assignable license permitting Customer to maintain the Deliverables if Supplier ceases support.]

Cooperation. Supplier will cooperate promptly with Customer's incident response and with any regulatory reporting, including making technical personnel available.

Flow-down. Supplier will impose equivalent obligations on its own suppliers.

Indemnity. Supplier will indemnify Customer for claims arising from security defects in the Deliverables.

Template 10 — Recall / corrective action decision memorandum

CORRECTIVE ACTION DECISION                     DATE: ______
PREPARED AT THE DIRECTION OF COUNSEL

1. THE DEFECT
   Description / affected products and versions / units in field

2. WHAT WE KNEW AND WHEN
   [Chronology. This section will be read most carefully.]

3. HAZARD ASSESSMENT
   Failure mode / severity / probability / population at risk
   Incidents reported: ______

4. REPORTING
   15 U.S.C. 2064 analysis and conclusion
   Filed: ______   Other jurisdictions: ______

5. REMEDY OPTIONS CONSIDERED
   For each: description, expected reach, cost, time, residual risk
   [ ] Automatic firmware update
   [ ] Update requiring user action
   [ ] Server-side mitigation
   [ ] Configuration guidance
   [ ] Feature disablement
   [ ] Repair or replacement
   [ ] Refund

6. REMEDY SELECTED, AND WHY

7. REACH
   Update mechanism adoption on prior releases: ____%
   Expected reach of this campaign: ____
   Owners identifiable through: registration ___ / retailer ___ /
   cloud account ___ / warranty ___
   **RESIDUAL POPULATION AFTER CAMPAIGN: ______**

8. RESIDUAL RISK, AND WHY IT IS ACCEPTABLE

9. CAMPAIGN PLAN
   Channels / timing / tracking / completion target

10. APPROVED BY: ____________  TITLE: ______  DATE: ______

Section 7's residual population is the number that matters. A campaign reaching 88% of devices leaves 12% unaddressed, and for a serious hazard that is the remaining problem, not a rounding error.

Template 11 — Multi-jurisdiction reporting map

One page per product line. The incident lead uses this at midnight.

Standing rules:

1. One set of facts across all filings.
2. Initial notifications may be incomplete — file on time and supplement.
3. Track every supplement obligation to closure.
4. Sequence customer communication so customers do not learn from a public database first.
5. Document decisions NOT to report, with the standard applied and the facts known.

Template 12 — Marketing claim review

Trigger review for: "secure," "encrypted," "protected," "private," any certification or standard, any support period statement, and any comparative security claim.

The test: could an engineer demonstrate this is true today, and will it remain true through the product's life? "Bank-level encryption" on a product with unencrypted local traffic is the paradigm enforcement case under 15 U.S.C. § 45.

Template 13 — Tabletop exercise

Ninety minutes. Run it before you need it. It reveals more than any policy review.

SCENARIO
  At 4:40 pm on a Friday, a researcher emails your general
  support address: "Your [Product] can be commanded by any
  unauthenticated device on the same network. I can disable
  [safety function]. I intend to publish in 90 days."

QUESTIONS — ask each participant, do not let anyone defer
  1. Where does that email actually go? Who reads it?
  2. How long before someone technical sees it?
  3. Who decides whether it is real?
  4. Who assigns severity? Using what scale?
  5. Who asks whether this is a reportable product defect?
     Do they know the standard?
  6. Who talks to the researcher? By when?
  7. Can we patch it? For which product generations?
  8. How many devices in the field cannot be updated at all?
  9. Who decides to notify customers? What do we say?
 10. Which regulators, in which markets, on what clocks?
 11. Who talks to the press if this goes public on Monday?
 12. Who has authority to delay a shipment because of this?

OUTPUT
  A written list of gaps, each with an owner and a date.

The recurring findings: no monitored security address; escalation running through a support queue with a multi-day service level; nobody who knows the product safety reporting standard; and a legacy product population that cannot be patched.

Related documents

• Connected Device Security and Software Liability: Regulators, Standards, and the Duty to Patch
• Building a Product Security Program for Connected Devices: A Practical Guide
• Connected Device Compliance Checklist: A Practical Checklist
• Cybersecurity Program Toolkit
• Data Breach and Incident Response Toolkit: From Detection to Notification
• Crisis Management and Business Continuity Toolkit
• Software and Open Source Licensing Toolkit: From IP Layers to Compliance Programs