Secure by Design is frequently reduced to secure coding training and vulnerability scanning. That interpretation misses the central shift: software manufacturers should design products so customers receive strong security outcomes without being forced to discover, purchase and configure basic protections themselves.
A Secure by Design assessment therefore cannot be a checklist performed only by the application-security team. It must examine product decisions, architecture, defaults, identity, development practices, vulnerability response, supply-chain controls, customer evidence and executive accountability.
The assessment should produce prioritised engineering change, not a ceremonial maturity score. Its purpose is to find where the product transfers avoidable security risk to customers and to create a funded plan for changing that design.
Define the assessment scope
Start with a product or coherent product family, not the entire company. Record supported deployment models, customer types, sensitive data, privileged functions, external integrations and critical dependencies.
Map the lifecycle from product requirements through design, development, build, release, deployment, update and end of support. Include cloud services, client software, firmware and operational consoles where relevant.
Define assessment evidence. Policy documents alone are insufficient. Review architecture, source and pipeline controls, test results, product configuration, telemetry, customer documentation, incident records and actual default behaviour.
Separate Secure by Design from Secure by Default
Secure by Design concerns the decisions made throughout product conception and engineering: threat modelling, identity architecture, memory safety, isolation, update design and reduction of attack surface.
Secure by Default concerns the state customers receive. Strong controls should be enabled, sensible and usable without expert configuration. Insecure legacy protocols, shared default credentials and broad privileges should not be the easiest path.
Assess both. A sound architecture can still ship with unsafe defaults, and strong defaults can sit on top of a fragile design.
Establish product-security accountability
Identify an executive accountable for product security outcomes and a product-level owner empowered to prioritise remediation. Engineering, product, security, support and legal all contribute, but distributed contribution must not mean ambiguous accountability.
Examine whether security requirements enter product planning, whether high-risk findings can block release and whether teams receive capacity to remove systemic weaknesses.
Review incentives. If roadmap delivery is measured but secure defaults, remediation and maintenance are not, the operating model will repeatedly trade security away.
Assess threat modelling and security requirements
Threat modelling should occur when design choices remain changeable, not immediately before launch. Evaluate whether teams identify assets, trust boundaries, attacker capabilities, abuse cases and failure consequences.
Sample recent features. Confirm that identified risks became explicit requirements, tests or architecture changes. Look for privacy, fraud, tenant isolation, administrative misuse, availability and supply-chain threats—not only injection vulnerabilities.
Create reusable threat patterns for common product capabilities such as file upload, webhooks, AI agents, plugins, identity federation and privileged support access.
Review identity and access architecture
Identity is a primary product-security boundary. Assess administrator accounts, workforce access, service identities, API credentials, sessions and recovery mechanisms.
Strong multi-factor authentication should be available and, where appropriate, required for privileged access without imposing an unreasonable premium. Eliminate shared or default credentials. Support least privilege, meaningful roles, session revocation and secure recovery.
Evaluate tenant isolation independently of user roles. Test whether identifiers, exports, search, caches and background jobs can cross boundaries.
For machine identities, review issuance, rotation, storage, scope and auditability. Long-lived broad tokens are an architectural debt, not merely a secret-scanning finding.
Evaluate secure defaults and configuration burden
Install or create a new tenant using default settings and observe the resulting security posture. This is one of the most revealing assessment activities.
Check exposure, authentication, administrative access, audit logging, encryption, sharing, API access, network controls and update behaviour. Identify controls that exist but are disabled, hidden, difficult to understand or sold only in premium tiers despite being essential.
Measure how many decisions a customer must make to reach the recommended baseline. A secure product minimises dangerous choice and explains unavoidable trade-offs clearly.
Examine attack-surface reduction
Inventory internet-facing endpoints, privileged APIs, legacy protocols, debug features, sample credentials, unused services and administrative interfaces.
Require explicit business justification and ownership for exposed capability. Remove obsolete code paths rather than relying indefinitely on warnings. Isolate optional high-risk components and avoid installing them by default.
Review language and component choices for memory-safety and exploitability. Where memory-unsafe code remains in exposed critical paths, require a roadmap based on risk and feasibility rather than a generic aspiration.
Assess the secure development lifecycle
Review how code changes are authenticated, reviewed, tested and released. Branch protection, peer review and automated checks should be proportionate to risk.
Evaluate static analysis, dependency analysis, secret detection, infrastructure scanning, dynamic testing and fuzzing. The existence of tools is not enough. Sample findings to see whether they are triaged, suppressed responsibly and connected to ownership.
Assess developer environments and AI coding tools. Determine what code and secrets can be sent to external systems, how generated code is reviewed and whether repositories protect sensitive branches and build configuration.
Review the software supply chain
Map source, dependencies, build services, artefact repositories, signing systems and release channels. Verify that production artefacts can be traced to reviewed source and controlled builds.
Protect build identities and signing keys. Restrict who can alter pipeline definitions and release artefacts. Generate a software bill of materials where customer, regulatory or operational needs justify it, and ensure it corresponds to the released product.
Evaluate dependency update and vulnerability response. A generated SBOM without ownership, monitoring and remediation does not reduce risk.
Assess vulnerability management and disclosure
A mature product provides a clear vulnerability disclosure channel, protects reporters acting in good faith and coordinates remediation and communication.
Measure time from report to triage, containment, fix, release and customer notification by severity and exploitation status. Review whether known exploited vulnerabilities receive accelerated treatment.
Examine root-cause analysis. If multiple vulnerabilities arise from the same unsafe pattern, the response should include platform, framework or design changes—not only individual patches.
Customers need supported-version clarity and actionable upgrade guidance. Security updates that are technically available but operationally impractical do not create the intended outcome.
Review logging, detection and customer evidence
Products should generate useful security telemetry without exposing secrets or excessive personal data. Assess administrative actions, authentication events, permission changes, exports, API keys and high-risk configuration changes.
Logs need consistent time, integrity, retention controls and export mechanisms. Customers should be able to integrate relevant events with their monitoring systems.
Do not claim that logging transfers responsibility to the customer. Product-side abuse detection and response remain necessary for hosted services.
Evaluate resilience and safe failure
Security includes availability and recovery. Review rate limiting, resource isolation, backup protection, restoration testing, regional failure and dependency failure.
Test whether the product fails open or closed at important authorisation and policy boundaries. A central policy service outage should not silently grant access. At the same time, safety-critical use cases may require carefully designed degraded modes.
Examine update rollback and key recovery. Resilience mechanisms must not become privileged bypasses.
Include AI features in the assessment
AI features introduce data disclosure, prompt injection, unsafe tool use, model supply-chain and output-integrity risks. Map what data enters prompts, retrieval indexes, training, logs and evaluation systems.
For RAG, enforce source permissions before retrieval. For agents, scope tool credentials and require approval for consequential actions. Treat retrieved and external content as untrusted instructions.
Evaluate model and prompt changes through versioned tests. Monitor security outcomes after release because behaviour cannot be fully established through traditional code review.
Build an evidence-based scoring model
Score capabilities using observable states such as absent, ad hoc, defined, implemented and measured. Require evidence for each rating.
Weight findings by customer harm, exploitability, exposure, privilege and prevalence. A weak control affecting every new tenant should rank above a documentation gap with limited consequence.
Avoid collapsing everything into one number. Present domain scores, critical design gaps and confidence in the evidence. Executives need to see where risk concentrates and what investment changes it.
Convert findings into engineering work
Every material finding should identify the affected product behaviour, threat, evidence, recommended target state, owner and milestone.
Prioritise systemic changes: secure configuration templates, central identity controls, safer frameworks, shared pipeline protections and removal of dangerous defaults. These changes prevent classes of defects.
Place remediation in the product roadmap and fund it. Track risk acceptance with approver, rationale and expiry. An assessment without budget and delivery ownership is documentation, not risk reduction.
A practical assessment sequence
During preparation, define scope, collect architecture and product evidence, and select representative deployments.
During fieldwork, interview engineering and product teams, inspect pipelines and configurations, test default deployments, sample recent changes and trace vulnerabilities through response.
During synthesis, validate findings with owners, distinguish evidence gaps from control failures and prioritise by customer outcome.
During remediation, confirm target architecture, sequence foundational changes and establish measures. Reassess high-risk controls after implementation rather than accepting screenshots or policy updates.
Questions buyers and customers increasingly ask
Software buyers want to know whether multi-factor authentication is included, how tenant data is isolated, how vulnerabilities are disclosed, whether releases are traceable, how quickly exploited flaws are addressed and what happens at end of support.
Prepare honest, reusable evidence through a product-security portal, security whitepaper, attestations and controlled technical documentation. Avoid absolute claims such as “completely secure.”
Procurement evidence should match the actual product tier and deployment model. A control available only in one enterprise edition should not be presented as universal.
Common assessment mistakes
The first mistake is treating scanner output as the assessment. The second is reviewing policies without testing defaults. The third is scoring teams rather than product outcomes.
Other failures include excluding build infrastructure, ignoring customer configuration burden, accepting “compensating control” without testing it, overlooking end-of-life versions and treating AI features as ordinary application endpoints.
The assessment must also avoid becoming a compliance mapping exercise disconnected from engineering reality.
Final recommendation
Assess Secure by Design at the product level, from architecture and incentives through default deployment and customer operations. Use evidence, test real behaviour and prioritise systemic changes that eliminate risk for many customers at once.
The defining question is not whether the company offers security features. It is whether the product reliably delivers a secure outcome without requiring every customer to become an expert or absorb risks the manufacturer was better positioned to prevent.
Sources and further reading
CISA Secure by Design
CISA and FBI Product Security Bad Practices
CIS and SAFECode Secure by Design assessment guidance
NIST Secure Software Development Framework
Example assessment evidence
For identity, evidence may include default tenant configuration, role definitions, recovery flows, MFA enforcement and penetration-test results. For supply chain, review protected pipeline configuration, provenance, signing controls, dependency inventory and a released artefact traced to source.
For vulnerability response, sample a critical report from receipt through triage, fix, release and customer communication. For secure defaults, create a clean deployment and test exposure without applying internal hardening instructions.
Prioritisation model
Classify findings as customer-risk transfer, systemic design weakness, unsafe default, lifecycle-control gap or evidence gap. Score likely harm, reachable exposure, affected population and remediation leverage.
Prioritise changes that remove entire classes of failure: eliminating shared credentials, making MFA standard, isolating tenants structurally, protecting release pipelines and automatically enabling audit logs. These usually provide more durable value than processing a long queue of isolated low-severity findings.
Governance cadence
Product security leaders should review critical findings monthly with engineering and product executives. Quarterly reviews should examine trends, expired risk acceptances, supported-version exposure and customer-impact measures.
Board reporting should focus on material product risks, remediation progress and systemic capability, not scanner counts. Teams need operational measures; executives need the decisions and resources required to change risk.
Definition of done
A remediation is complete when product behaviour, tests, documentation, telemetry and rollout all reflect the target state. A code merge alone is not completion if existing tenants remain unsafe or customers cannot adopt the control.
Verify the fix against a clean deployment and an upgraded existing deployment. Update threat models and support guidance. Reassess residual risk and close the finding only with evidence.
