Communication with Customers – A Technical and Strategic Guide to Secure Software Transparency
Background and Structure
This part of the Software Security Code of Practice complements the other three (Secure Design, Build Environment, Deployment and Maintenance) by ensuring that security does not end at code delivery, but continues through transparency and open communication with users and integrators.
Part 4 is evaluated through the UK government’s Assurance, Principles & Claims (APC) model. A Senior Responsible Owner (SRO), typically a director-level or VP-level leader, must ensure these practices are adopted across product, support, engineering, and communications teams.
Objective
To establish trust, support customer risk management, and meet contractual or regulatory obligations by proactively communicating security-relevant information. This includes lifecycle policies, incident notifications, and remediation guidance.
Core Principles of Part 4: Customer Communication
1. Lifecycle Documentation and Visibility
What This Means
Allow customers to plan upgrades, risk mitigation, and security patching by publishing clear and predictable software support timelines.
Implementation
Define Lifecycle Stages for Each Product
Document the following for each major release, version line, or product:
- Release date
- Active support period
- Security-fix support period
- End-of-life (EOL) date
- Post-EOL options (e.g., extended support)
These should be:
- Machine-readable (e.g., JSON or YAML for APIs/integrators)
- Published on your website and developer portals
Provide at Least 12 Months’ Notice for EOL
- Automate alerts for internal and external users when a product is 12 months from EOL.
- Notify customers via email, support portals, and public documentation.
Potentially useful tools:
- Commercial: Salesforce Service Cloud or Atlassian Jira Service Management (with lifecycle notification workflows)
- Open Source: Documize for publishing lifecycle docs, or static site generators like MkDocs
Maintain a Version Support Matrix
Publish a version matrix table that clearly shows:
- Which versions are in full support
- Which are in security-only support
- Which are EOL
Best Practice: Include lifecycle metadata in your product’s API or CLI via –version or /metadata endpoints.
2. Security Incident Reporting and Response Communication
What This Means
Ensure that customers receive timely, accurate, and actionable information when security incidents or vulnerabilities could impact their environments.
Implementation
Establish Predefined Customer Communication Channels
Security advisories should be published via multiple channels:
- RSS or Atom feeds
- Email lists (opt-in)
- Customer portals or service dashboards
- Developer blog or changelog
Ensure all comms reference a common incident ID (e.g., SEC-2025-003) and provide links to detailed post-mortems where applicable.
Define Notification Triggers
Triggers for customer notifications should include:
- Discovery of vulnerabilities that affect deployed code
- Data breaches or credential leakage
- Software misconfiguration that could cause systemic risk
- Suspicious behaviour or signs of compromise in distributed software
Potentially useful tools:
- Commercial: PagerDuty with StatusPage integration, or Atlassian Opsgenie + Confluence for advisories
- Open Source: Cortex XSOAR Community Edition, Zinc for alert publishing
Deliver Post-Incident Reports
Where applicable, publish a customer-facing summary of:
- What happened
- Which systems or data were impacted
- How it was resolved
- Steps customers should take (patch, reconfigure, rotate credentials, etc.)
- Improvements made to prevent recurrence
Post-incident reports should avoid assigning blame and focus on transparency, timelines, and remediation.
Evaluating Compliance
The Senior Responsible Owner (SRO) should lead regular evaluations to determine whether customer-facing security communication is compliant and effective. The following questions are a starting point:
| Assessment Area | Key Questions |
| Lifecycle Visibility | Is a lifecycle policy publicly available and easy to understand? Do you provide a 12-month advance notice for EOL products? |
| Customer Notification | Can customers easily subscribe to security notifications? Are all critical incidents communicated within your SLA (e.g., 48 hours)? |
| Remediation Support | Do incident reports include actionable steps for affected users? Are internal and external versions of postmortems maintained? |
| Accessibility & Accessibility | Are your security comms accessible to non-technical audiences (e.g., procurement, IT security)? |
Organisational Support: Enabling Customer-Centric Security Communication
Governance
- Policy Ownership: Assign lifecycle and incident communication policies to the product or customer success function.
- Templates and Playbooks: Standardise advisory, bulletin, and postmortem templates to reduce delay and inconsistency.
- Legal and PR Review Workflows: Pre-approve security communication workflows to reduce bottlenecks during an incident.
Cross-Team Collaboration
- Security + Marketing: Ensure that security teams can publish communications without unnecessary branding or marketing delay.
- Product + Legal: Work together to define lifecycle obligations for customers under SLA, licensing, or procurement contracts.
Automation
- Advisory Syndication: Automatically syndicate new advisories to GitHub Security Advisories, mailing lists, and changelogs.
- Ticket Generation: Trigger automated Jira or ServiceNow tickets for customers when their deployed version approaches EOL.
Tooling Summary: Some Potentially Useful Solutions
| Function | Commercial Tool | Open Source Alternative |
| Lifecycle Policy Management | Salesforce Knowledge, Jira Service Mgmt | Documize, MkDocs |
| Security Notification Management | PagerDuty + StatusPage | Zabbix or Cortex + Zinc |
| Incident Playbooks & Response | Atlassian Opsgenie, ServiceNow IR | TheHive + Cortex |
| VDP / Customer Security Reporting | HackerOne, Bugcrowd | security.txt + Disclose.io templates |
| Public Communication | GitHub Security Advisories | RSS/Atom feeds, self-hosted changelogs |
Final Recommendations on aligning with the UK Software Security Code of Practice
- Make transparency a default posture, not a legal fallback. Customers reward vendors who communicate early and honestly.
- Establish internal thresholds for incident severity and corresponding communication timelines (e.g., <24h for high-impact vulnerabilities).
- Treat customer trust as a security control, your ability to notify, guide, and support during security events is part of your risk surface.
Missed part 3? Find it at https://clearpathsecurity.co.uk/part-3-of-aligning-with-the-uks-software-security-code-of-practice
Comments are closed