Software Factory Security Framework (SF²)¶

A Complete Mental Model for Securing Software Factories at Scale¶

Welcome¶

The Software Factory Security Framework (SF²) provides security leaders with a strategic approach to scaling security capabilities while improving business outcomes.

Whether you're leading security for a three-person startup or a multinational corporation, this framework helps you:

✅ Understand universal security responsibilities that apply to every software-producing organization
✅ Position your organization strategically using a two-axis assessment model
✅ Invest resources effectively by balancing immediate needs with long-term scaling
✅ Adapt to your context using modifiers that account for your specific constraints

Framework Overview¶

The Security Scaling Challenge¶

Every security leader eventually confronts the same fundamental challenge: the day when demand for security services begins to outpace your team's capacity to deliver them.

The traditional response—hiring more security professionals—provides temporary relief but becomes increasingly difficult to sustain. This framework presents a different approach: strategic resource allocation that enables sustainable security scaling while improving business outcomes.

Strategic Opportunity¶

Organizations that successfully navigate this challenge don't just solve a scaling problem—they create competitive advantages:

Faster time-to-market
Higher developer productivity
More robust security postures
Better business alignment

What This Framework Provides¶

Universal Stewardship Model

Five core security responsibilities that apply to every software-producing organization

Learn more
Strategic Positioning Tool

Two-axis framework for understanding your organization's current state and optimal path forward

Assess your position
Investment Portfolio Approach

Systematic method for balancing immediate security needs with long-term scaling capabilities

Explore investments
Contextual Adaptation Guide

How to modify implementation approaches based on your specific organizational constraints and opportunities

Understand modifiers

Strategic Context¶

Adversary Evolution

In recent years, attackers shifted from targeted reconnaissance to automated discovery at internet scale—sweeping billions of assets to find vulnerabilities. Organizations using manual security processes face a fundamental capability gap: attackers can discover unknown systems faster than defenders can catalog them.

Understanding these adversary evolution patterns helps security leaders prioritize investments that shift economic advantage away from attackers.

How This Framework Complements Existing Standards¶

SF² works alongside existing security methodologies (NIST SSDF, OWASP SAMM, BSIMM) by addressing the strategic resource allocation and organizational change questions they don't answer:

Framework	Focus	SF² Relationship
NIST SSDF	Secure development practices	SF² addresses sustainable resourcing at scale
OWASP SAMM	Security practice maturity	SF² contextualizes implementation based on readiness
BSIMM	Security activity benchmarking	SF² determines investment priorities
OWASP ASVS	Security verification requirements	SF² helps sequence implementation

See detailed framework relationships

Quick Start¶

For Security Leaders¶

Read the Executive Summary
Assess your Strategic Position
Review Implementation Guide for your quadrant
Evaluate Contextual Modifiers

For Individual Contributors¶

Understand Universal Stewardship Responsibilities
Explore Use Cases relevant to your role
Reference specific stewardship areas as needed

For Consultants & Advisors¶

Review complete Framework Structure
Study Strategic Positioning Model
Understand Investment Portfolio Approach

Framework Principles¶

Executive Insight

Security scaling isn't primarily solved through capacity increases alone—it requires strategic investment in capabilities that reduce manual effort requirements. Organizations that make this shift successfully report significant improvements in both security effectiveness and business velocity.

Core Principles¶

Scale-Agnostic: Applies from startups to enterprises
Technology-Agnostic: Works with any tech stack or infrastructure
Business-Aligned: Ties security investments to business outcomes
Adaptation-Focused: Recognizes organizational context matters
Adversary-Aware: Accounts for how attackers evolve

About This Framework¶

Author: Julie Davila License: CC BY 4.0 Version: 0.4.0

This framework represents my personal strategic mental models for security leadership, developed through years of experience leading product security at scale. While I currently serve as VP of Security at GitLab, SF² is not an official GitLab framework and does not formally represent GitLab's views.

That said, these mental models do inform how I approach security strategy at GitLab. To the extent I have strategic influence over GitLab's security posture, the principles in SF² reflect my underlying approach to securing software factories at scale.

This is an open source framework (CC BY 4.0) intended as a resource for the broader security community.

Contributing Guidelines View on GitLab

What's Next?¶

Start Here

Begin with the Executive Summary to understand the framework's strategic context and key concepts.

Assess Your Organization

Use the Two-Axis Positioning Model to determine your current state and optimal path forward.

Implement Strategically

Follow your quadrant-specific Implementation Guide for actionable next steps.

Executive Summary¶

The Security Scaling Challenge Every Leader Faces¶

Every security leader eventually confronts the same fundamental challenge: the day when demand for security services begins to outpace your team's capacity to deliver them. You're managing an increasing volume of security reviews, compliance requests, and incident responses while your organization demands faster innovation and delivery.

The traditional response—hiring more security professionals—provides temporary relief but becomes increasingly difficult to sustain. This framework presents a different approach: strategic resource allocation that enables sustainable security scaling while improving business outcomes.

The Strategic Opportunity¶

Organizations that successfully navigate this challenge don't just solve a scaling problem—they create competitive advantages. They achieve faster time-to-market, higher developer productivity, and more robust security postures simultaneously. This transformation requires understanding that security scaling is fundamentally a strategic and organizational challenge, not just a technical one.

Framework Overview¶

The Software Factory Security Framework (SF²) provides security leaders with:

Universal Stewardship Model¶

Five core security responsibilities that apply to every software-producing organization:

Supply Chain (#1 Priority) - Managing security risks from all external dependencies
Process - Security embedded throughout development lifecycle
Runtime - Maintaining security of systems in production
Third-Party - Managing risks from integrated services and platforms
Continuous Learning - Evolving security practices based on experience

Learn more about stewardship

Strategic Positioning Tool¶

Two-axis framework for understanding your organization's current state:

Operational Complexity (What you manage): Simple → Complex
Operational Readiness (How you operate): Lower → Higher

This creates four strategic positions: Visionaries, Leaders, Niche Players, and Challengers.

Assess your position

Investment Portfolio Approach¶

Systematic method for balancing security investments:

BAU Activities (Constrain): Manual work that scales with growth
Scaling Investments (Prioritize): Capabilities that reduce manual effort
Platform Effects (Multiply): Benefits that serve internal and external value

Explore investment strategy

Contextual Adaptation Guide¶

Six modifiers that influence your implementation approach:

Attack Landscape Maturity
Supply Chain Complexity
Regulatory Constraints
Crisis Events
Change Capacity
Relationship Health

Understand your context

Strategic Context: Adversary Evolution¶

Critical Shift in Adversary Capabilities

In recent years, attackers shifted from targeted reconnaissance to automated discovery at internet scale—sweeping billions of assets to find vulnerabilities.

Organizations using manual security processes face a fundamental capability gap: attackers can discover unknown systems faster than defenders can catalog them.

Understanding these adversary evolution patterns helps security leaders prioritize investments that shift economic advantage away from attackers.

How This Framework Works¶

This framework works alongside existing security methodologies (NIST SSDF, OWASP SAMM, BSIMM) by addressing the strategic resource allocation and organizational change questions they don't answer.

Your Question	SF² Answer
How do I sustainably invest in security as we scale?	Investment Portfolio Framework
How do I adapt security approaches to my org?	Strategic Positioning + Contextual Modifiers
How do I align security with business outcomes?	Platform Effects + Business Integration

Executive Insight¶

Quote

Security scaling isn't primarily solved through capacity increases alone—it requires strategic investment in capabilities that reduce manual effort requirements.

Organizations that make this shift successfully report significant improvements in both security effectiveness and business velocity.

Getting Started¶

Three Steps to Apply This Framework¶

Assess Your Position: Use the Two-Axis Model to understand your current state
Evaluate Context: Review Contextual Modifiers that influence your approach
Implement Strategically: Follow your Implementation Guide for actionable next steps

Ready to dive deeper? Start with Foundation: Software Factory Definition to understand the core concepts.

Continue to Foundation

Foundation

Foundation: Software Factory Definition¶

The Universal Challenge¶

Whether you're leading security for a three-person startup or a multinational corporation, you face the same fundamental question: How do you maintain security accountability for code-based systems that deliver value to end users?

This responsibility spans your entire value delivery chain—from internal development through third-party dependencies to production operations.

What is a Software Factory?¶

Definition

A software factory is an organization that bears operational responsibility for deploying, maintaining, and evolving code-based systems that deliver value to end users, including systematic risk stewardship across all components in their value delivery chain—whether directly controlled or third-party.

This definition encompasses:

Scale Agnostic: From single-developer startups to enterprise organizations
Technology Agnostic: Any tech stack, deployment model, or infrastructure approach
Responsibility Focused: Emphasis on operational accountability rather than just code ownership
Third-Party Inclusive: Recognition that modern software depends extensively on external components

Key Characteristics¶

Operational Responsibility¶

Software factories are accountable for how code reaches end users and impacts their experience, regardless of whether every component is built in-house.

Value Delivery Chain¶

The entire pipeline from code creation through production deployment and ongoing operations.

Risk Stewardship¶

Ongoing responsibility for understanding, assessing, and responding to security risks across the complete software stack.

Systematic Processes¶

Repeatable, improvable approaches to software creation and deployment rather than ad-hoc development.

Why This Definition Matters¶

Understanding your organization as a software factory helps clarify:

Scope of Responsibility: You're accountable for security across the entire value delivery chain, not just code you write
Third-Party Dependencies: External components are part of your security responsibility
Operational Focus: Security accountability extends through production operations
Universal Applicability: The same framework applies regardless of organization size or technology choices

How This Framework Complements Existing Security Standards¶

SF² addresses strategic questions that existing frameworks don't answer:

Resource Allocation Strategy: How do you sustainably invest in security as your organization scales?
Contextual Implementation: How do you adapt security approaches to your specific organizational reality?
Business Integration: How do you align security investments with business outcomes and competitive advantage?

Framework Relationships¶

Framework	Primary Focus	SF² Relationship	When to Use Together
NIST SSDF	Secure development lifecycle practices	SF² addresses sustainable resourcing of SSDF practices at scale	Use SSDF for development security practices, SF² for sustainable implementation strategy
OWASP SAMM	Security practice maturity progression	SF² contextualizes SAMM implementation based on organizational readiness	Implementation speed and scope vary by organizational complexity and readiness level
BSIMM	Security activity measurement and benchmarking	SF² determines investment priorities for BSIMM activities based on organizational positioning	Use SF² assessment to guide BSIMM implementation scope and sequencing
OWASP ASVS	Security verification requirements	SF² helps sequence ASVS implementation within scaling investment strategy	Use SF² to determine risk-based ASVS subset vs. comprehensive implementation

Examples of Software Factories¶

To illustrate the universal nature of this definition:

Startup Software Factory¶

Team: 5 developers
Product: SaaS application
Value Chain: Cloud infrastructure (AWS), development tools (GitHub), monitoring (Datadog), dozens of open-source dependencies
Security Responsibility: Entire stack, despite building ~5% of code themselves

Enterprise Software Factory¶

Team: 500+ developers across multiple teams
Products: Multiple applications and services
Value Chain: Multi-cloud infrastructure, extensive third-party integrations, internal platform services, hundreds of dependencies
Security Responsibility: Complex ecosystem with multiple ownership boundaries but unified accountability to end users

Platform Software Factory¶

Team: 50 platform engineers
Product: Internal developer platform
Value Chain: Kubernetes infrastructure, CI/CD pipelines, security tooling, compliance automation
Security Responsibility: Enabling other teams while maintaining platform security posture

Common Thread

In each case, security responsibility extends far beyond code directly written by the organization. The software factory definition emphasizes this operational accountability across the complete value delivery chain.

Next Steps¶

Now that you understand what constitutes a software factory, the next section explores the five universal security responsibilities that every software factory must address.

Continue to Universal Stewardship Back to Executive Summary

Universal Stewardship

Universal Risk Stewardship Responsibilities¶

The Common Ground Across All Software Factories¶

Regardless of size, technology stack, or industry, every software factory must address five core stewardship areas. These represent the fundamental security responsibilities that scale with your organization.

Universal Applicability

These stewardship responsibilities apply to every software-producing organization—from three-person startups to multinational enterprises. The specific implementation approaches vary based on your strategic position, but the responsibilities themselves are universal.

The Five Stewardship Areas¶

Stewardship Area	Core Responsibility	Why Universal
Supply Chain (#1 Priority)	Managing security risks from all external dependencies and third-party components throughout their lifecycle	Modern software depends heavily on external components—even simple applications typically incorporate dozens of third-party dependencies
Process	Security embedded throughout development lifecycle with continuous validation and rapid feedback loops	Development process directly impacts security outcomes regardless of sophistication level
Runtime	Maintaining security and reliability of systems in production with proactive monitoring and rapid response capabilities	Once serving users, organization becomes directly responsible for security behavior in production
Third-Party	Managing security risks from integrated services, platforms, and vendors throughout operational lifecycle	Modern software factories integrate with cloud providers, monitoring services, development tools, business platforms
Continuous Learning	Evolving security practices based on experience, incidents, and changing threat landscape while building organizational capability	Security landscape continuously evolves through new threats, technologies, organizational changes

Key Focus Areas by Stewardship Area¶

Supply Chain (#1 Priority)¶

Dependency monitoring with automated vulnerability detection
Vendor security evaluation and relationship management
Supply chain attack detection and response planning
License compliance integrated with procurement

Success Indicators: Dependency mapping coverage, vendor security assessment completion, supply chain incident response readiness

Process¶

Pipeline security controls with automated continuous testing
Code review effectiveness integrated with quality processes
Secret management with automated rotation
Environment consistency with drift prevention
Security-quality integration

Success Indicators: Developer satisfaction scores, security-quality integration metrics, continuous validation effectiveness

Runtime¶

Production monitoring with automated incident detection
Incident response readiness and execution
Data protection with access controls
Performance-security balance optimization

Success Indicators: Incident response time, monitoring coverage effectiveness, customer impact assessment quality

Third-Party¶

Integration security risk management
Shared responsibility model clarity and enforcement
Service provider security monitoring
Contingency planning with tested procedures

Success Indicators: Integration assessment coverage, shared responsibility validation, contingency plan testing

Continuous Learning¶

Risk monitoring with predictive insights
Feedback loop optimization
Blameless post-mortems with lessons learned integration
Knowledge sharing with cross-functional collaboration

Success Indicators: Learning culture indicators, improvement cycle effectiveness, knowledge transfer success rates

Strategic Insight¶

Implementation Varies, Responsibilities Don't

These stewardship responsibilities are universal, but implementation approaches must scale appropriately to organizational complexity and readiness.

A three-person startup and a 500-person enterprise both need supply chain stewardship, but their implementations will look dramatically different. The Strategic Positioning section provides frameworks for making these strategic implementation decisions.

How Stewardship Areas Interact¶

The five stewardship areas are interconnected:

Supply Chain risks can manifest during Runtime
Process improvements enable better Third-Party integration security
Continuous Learning informs improvements across all other areas
Runtime incidents drive Process improvements
Third-Party security depends on Supply Chain visibility

Understanding these interactions helps you prioritize investments that create cascading benefits across multiple stewardship areas.

Next Steps¶

Explore each stewardship area in detail, starting with the highest priority:

Supply Chain Stewardship (#1 Priority) Process Stewardship Runtime Stewardship

Back to Foundation

Supply Chain Stewardship (#1 Priority)¶

Critical Priority

Supply chain security became an existential priority when attackers evolved from targeted reconnaissance to automated discovery at internet scale.

The Critical Shift¶

The Modern Reality: In recent years, attackers fundamentally changed their approach. Instead of targeted reconnaissance against specific organizations, adversaries began using bug bounty techniques and internet-wide scanning to discover vulnerabilities at scale—sweeping billions of assets to find exploitable weaknesses.

The Capability Gap: Today's attackers can discover unknown assets—forgotten servers, shadow IT, unmanaged dependencies—faster than most organizations can inventory them. This creates a fundamental asymmetry:

Defenders: Quarterly asset inventories, manual dependency tracking, periodic vulnerability scans
Attackers: Continuous automated discovery, real-time vulnerability exploitation, internet-scale reconnaissance

Why This Became #1 Priority

The adversary capability advantage in the supply chain isn't about dependency volume—it's about discovery speed. When attackers can find your unknown assets faster than you can catalog them, supply chain security becomes existential regardless of your other security investments.

The Dependency Reality¶

Modern software depends heavily on external components—libraries, frameworks, services, and platforms. Even simple applications incorporate dozens of third-party dependencies. This complexity, combined with automated adversary reconnaissance, creates the fundamental challenge:

Organizations relying on quarterly asset inventories face adversaries who discover vulnerabilities continuously at internet scale.

Core Responsibility¶

Managing security risks from all external dependencies and third-party components throughout their lifecycle, including:

Software libraries and frameworks
Development tools and build systems
Cloud infrastructure and services
Third-party APIs and integrations
Open-source components
Commercial software vendors

Key Focus Areas¶

1. Dependency Risk Assessment and Ongoing Monitoring¶

Automated Vulnerability Detection:

Continuous scanning of dependency manifests (package.json, requirements.txt, pom.xml, etc.)
Real-time alerting for new vulnerabilities in existing dependencies
Automated pull requests for security updates
Integration with build pipelines for early detection

Dependency Mapping Coverage:

Complete inventory of direct and transitive dependencies
Version tracking across all environments
License compliance monitoring
End-of-life (EOL) component identification

Maturity Progression

Basic: Manual quarterly dependency audits
Intermediate: Automated scanning in CI/CD pipelines
Advanced: Real-time monitoring with automated remediation, SBOM generation

2. Vendor Security Evaluation and Relationship Management¶

Security Requirements:

Pre-procurement security assessments
Ongoing vendor security monitoring
Incident notification requirements
Security update SLAs

Relationship Management:

Clear communication channels for security issues
Regular vendor security posture reviews
Contingency planning for vendor security incidents
Contract clauses for security requirements

3. Supply Chain Attack Detection and Response Planning¶

Detection Capabilities:

Dependency confusion attack monitoring
Typosquatting detection
Compromised package identification
Build system integrity validation

Response Planning:

Incident coordination procedures with vendors
Rollback and remediation strategies
Communication templates for customers
Post-incident review processes

Real-World Attack Patterns

Recent supply chain attacks include:

Dependency Confusion: Attackers upload malicious packages with names similar to internal dependencies
Compromised Maintainers: Legitimate packages taken over through compromised credentials
Typosquatting: Malicious packages with names similar to popular libraries
Build System Compromises: Attackers inject malicious code during build processes

4. License Compliance Integrated with Procurement¶

Legal Risk Management:

Automated license detection and tracking
Compliance policy enforcement
Legal review integration for procurement
License incompatibility detection

Procurement Integration:

Security requirements in vendor contracts
License approval workflows
Compliance documentation generation
Audit trail maintenance

5. Continuous Dependency Updates¶

Balancing Security and Stability:

Automated security patch application
Compatibility testing before updates
Staged rollout strategies
Rollback procedures for problematic updates

Update Prioritization:

Critical security patches: Immediate application
High-severity vulnerabilities: 24-48 hour SLA
Medium/low severity: Regular update cycles
Breaking changes: Planned migration windows

Success Indicators¶

Indicator	Description	Target
Dependency Mapping Coverage	Percentage of dependencies with complete inventory	>95%
Vulnerability Detection Time	Time from CVE publication to detection in environment	<24 hours
Mean Time to Remediation (MTTR)	Average time from detection to patch deployment	Critical: <48 hours High: <7 days
Vendor Security Assessment Completion	Percentage of vendors with current security assessments	100% of critical vendors
Supply Chain Incident Response Readiness	Tested incident response procedures	Quarterly testing
Automated Update Rate	Percentage of security updates applied automatically	>80% for non-breaking changes

Implementation by Strategic Position¶

Visionaries (Simple + High Readiness)¶

Leverage cloud-native SBOM tools
Automate dependency updates with comprehensive testing
Implement policy-as-code for dependency governance
Use managed services for vulnerability scanning

Leaders (Complex + High Readiness)¶

Enterprise SBOM and dependency management platforms
Automated supply chain risk scoring
Cross-organization dependency policies
Supply chain security orchestration

Niche Players (Simple + Low Readiness)¶

Start with basic dependency scanning tools (Dependabot, Renovate)
Manual but systematic vendor assessments
Simple spreadsheet-based dependency tracking
Focus on critical dependencies first

Challengers (Complex + Low Readiness)¶

Pragmatic hybrid approach: automated scanning where possible, manual processes where necessary
Prioritize critical applications and services
Gradual expansion of automated capabilities
Leverage existing compliance infrastructure

Strategic Investments That Scale¶

Paved Roads for Supply Chain Security¶

Pre-approved Dependency Lists:

Vetted libraries and frameworks with security ratings
Self-service dependency addition with automated security checks
Clear documentation for common use cases
Regular review and updates based on threat intelligence

Automated Dependency Management:

Centralized dependency proxy/repository
Automated security scanning and policy enforcement
Integration with procurement and legal workflows
Continuous monitoring without manual effort

Developer Self-Service:

Dependency security dashboard with actionable insights
Automated remediation guidance
Integration with IDE and development tools
Friction-free security updates

Common Pitfalls¶

Anti-Patterns to Avoid

Manual-Only Approaches: Quarterly dependency audits can't keep pace with continuous adversary discovery

Alert Fatigue: Too many low-priority alerts reduce effectiveness; focus on critical vulnerabilities first

Blocking Without Alternatives: Blocking insecure dependencies without providing secure alternatives frustrates developers

Point-in-Time Compliance: Annual assessments miss the continuous nature of supply chain risks

Vendor Security Theater: Questionnaire-based vendor assessments without ongoing monitoring

Quick Start Checklist¶

For organizations starting supply chain stewardship:

[ ] Week 1: Implement basic dependency scanning in main repositories
[ ] Week 2: Create initial dependency inventory (direct dependencies only)
[ ] Week 3: Establish critical vendor list and initiate security assessments
[ ] Month 2: Automate vulnerability alerting and create response procedures
[ ] Month 3: Implement automated dependency updates for non-breaking changes
[ ] Quarter 2: Expand to transitive dependencies and develop SBOM capabilities
[ ] Quarter 3: Build self-service dependency management platform
[ ] Quarter 4: Establish continuous improvement processes based on lessons learned

Next Steps¶

Continue to Process Stewardship Back to Stewardship Overview

Process Stewardship¶

The Integration Challenge¶

Security controls must be embedded throughout your software development and deployment lifecycle with continuous validation and rapid feedback loops. The goal is security that enhances rather than impedes software quality and delivery velocity.

Core Responsibility¶

Ensuring security is integrated into your development processes in ways that improve overall system reliability and developer experience.

Security-Quality Integration

The most effective security processes serve dual purposes—they improve both security outcomes and overall software quality. When security and quality teams collaborate, improvements benefit both objectives.

Key Focus Areas¶

1. Pipeline Security Controls¶

Automated Continuous Testing:

Security testing integrated into CI/CD pipelines
Automated SAST (Static Application Security Testing) on every commit
DAST (Dynamic Application Security Testing) in staging environments
Container security scanning before deployment
Infrastructure-as-code security validation

Continuous Validation:

Policy-as-code enforcement at build time
Automated compliance checks
Security gates with clear remediation guidance
Fast feedback loops (< 10 minutes for most checks)

Developer Experience Matters

Security checks that take 2 hours to run will be bypassed. Fast feedback enables developers to fix issues immediately rather than context-switching days later.

2. Code Review Effectiveness¶

Security-Focused Reviews:

Automated code review for common security issues
Human review for sensitive changes (authentication, authorization, data handling)
Security champions program for peer review
Clear escalation paths for security questions

Integration with Quality Processes:

Security review as part of standard code review
Shared checklists for quality and security
Collaborative improvement of review processes
Metrics that measure both quality and security outcomes

3. Secret and Credential Management¶

Automated Secret Management:

Secrets never committed to source control
Automated secret scanning in repositories
Secrets rotation with minimal manual intervention
Comprehensive audit logging of secret access

Developer Self-Service:

Easy secret retrieval for authorized systems
Clear documentation and tooling
Integration with development environments
Minimal friction for legitimate use cases

Common Secret Management Failures

Hardcoded credentials in source code
Secrets stored in configuration files
Long-lived credentials without rotation
Overly broad secret access permissions

4. Environment Consistency and Drift Prevention¶

Configuration Management:

Infrastructure-as-code for all environments
Automated drift detection and remediation
Immutable infrastructure where possible
Configuration validation before deployment

Continuous Compliance:

Automated compliance policy enforcement
Regular environment scanning for configuration drift
Alerts for unauthorized changes
Automated remediation where safe

5. Change Risk Assessment¶

Automated Risk Evaluation:

Change impact analysis based on code diff
Automated determination of review requirements
Risk-based deployment strategies
Clear approval workflows

Reliable Rollback Capabilities:

Automated rollback procedures
Canary deployments for high-risk changes
Feature flags for gradual rollout
Monitoring and alerting for deployment issues

6. Developer Experience Monitoring¶

Friction Measurement:

Time to complete security reviews
Developer satisfaction with security processes
Frequency of security process bypasses
Developer understanding of security requirements

Systematic Improvement:

Regular developer feedback collection
Iterative process improvements
Automation of repetitive tasks
Clear documentation and self-service options

Success Indicators¶

Indicator	Description	Target
Developer Satisfaction Score	Survey rating of security process experience	>4.0/5.0
Security Test Execution Time	Average time for security pipeline checks	<10 minutes
Security Issue Fix Time	Average time from detection to fix	<24 hours for automated findings
Process Bypass Rate	Percentage of changes that skip security checks	<1%
Secrets Exposure Rate	Number of secrets accidentally committed	Zero tolerance
Environment Drift Detection	Time to detect configuration drift	<1 hour

Implementation by Strategic Position¶

Visionaries (Simple + High Readiness)¶

Cloud-native security scanning integrated into CI/CD
Policy-as-code from day one
Automated secrets management with cloud provider tools
Modern development environments with built-in security

Leaders (Complex + High Readiness)¶

Enterprise security orchestration platforms
Cross-organization policy governance
Advanced deployment strategies (canary, blue-green, progressive)
Comprehensive developer self-service security platforms

Niche Players (Simple + Low Readiness)¶

Basic CI/CD security scanning (start with SAST)
Manual but systematic code review for security
Simple secrets management (environment variables)
Gradual automation of repetitive tasks

Challengers (Complex + Low Readiness)¶

Pragmatic automation: start with highest-risk processes
Hybrid manual/automated approaches
Focus on critical applications first
Incremental improvements without disrupting delivery

Strategic Investments That Scale¶

Paved Roads for Secure Development¶

Secure Templates and Baselines:

Pre-approved architecture patterns
Secure code templates for common use cases
Default security configurations
Regular updates based on threat intelligence

Self-Service Security Platforms:

Automated environment provisioning with security baked in
One-click security testing and validation
Clear documentation and examples
Integration with existing development workflows

Security-Quality Integration:

Shared metrics and objectives
Collaborative improvement initiatives
Combined training and education
Unified incident response for quality and security issues

Common Pitfalls¶

Anti-Patterns to Avoid

Security Theater: Processes that appear rigorous but don't improve actual security

Manual Bottlenecks: Security reviews that delay releases without commensurate risk reduction

Alert Overload: Too many security findings with unclear prioritization

Blocking Without Guidance: Failing builds without clear remediation steps

Point-in-Time Checks: Security validation only at release time instead of continuously

Quick Start Checklist¶

For organizations starting process stewardship:

[ ] Week 1: Integrate basic SAST scanning into CI/CD for main repository
[ ] Week 2: Implement automated secret scanning on commits
[ ] Week 3: Establish security code review checklist and process
[ ] Month 2: Add DAST scanning in staging environment
[ ] Month 3: Implement automated secrets management solution
[ ] Quarter 2: Develop security-approved templates and patterns
[ ] Quarter 3: Build developer self-service security documentation
[ ] Quarter 4: Measure and optimize developer experience with security processes

Next Steps¶

Continue to Runtime Stewardship Back to Supply Chain Stewardship

Runtime Stewardship¶

The Production Reality¶

Once software serves end users, your organization becomes directly responsible for its security behavior in production environments. Runtime stewardship encompasses monitoring, incident response, data protection, and maintaining the balance between security and user experience.

Core Responsibility¶

Maintaining security and reliability of systems in production with proactive monitoring and rapid response capabilities.

Production Accountability

Runtime stewardship recognizes that security responsibility doesn't end at deployment—it intensifies. Production systems face real adversaries, real users, and real business impact.

Key Focus Areas¶

1. Production Monitoring and Alerting¶

Automated Incident Detection:

Real-time security event monitoring
Anomaly detection for suspicious behavior
Attack pattern recognition
Automated threat intelligence integration
Performance baseline monitoring

Effective Alerting:

Tuned alert thresholds to reduce false positives
Clear escalation procedures
Integration with incident response workflows
Automated triage for common event types
24/7 monitoring coverage

Alert Quality Over Quantity

One high-fidelity alert that triggers immediate response is more valuable than 100 low-quality alerts that create alert fatigue.

2. Incident Response Readiness and Execution¶

Preparedness:

Documented incident response playbooks
Regular incident response exercises
Clear roles and responsibilities
Communication templates and procedures
Post-incident review processes

Execution:

Rapid containment capabilities
Evidence preservation procedures
Customer communication protocols
Coordination with external parties (vendors, law enforcement)
Recovery and restoration processes

Success Metrics:

Time to detect (TTD): How quickly you identify security incidents
Time to contain (TTC): How fast you stop the incident from spreading
Time to recover (TTR): How soon you restore normal operations
Customer impact minimization

3. Data Protection and Access Controls¶

Data Security:

Encryption at rest and in transit
Data classification and handling procedures
Retention and deletion policies
Backup security and testing
Data loss prevention (DLP) controls

Access Management:

Principle of least privilege enforcement
Regular access reviews and certification
Privileged access management (PAM)
Audit logging of sensitive data access
Automated access provisioning and deprovisioning

Data Breach Prevention

Most data breaches result from compromised credentials or misconfigurations—not sophisticated zero-day exploits. Focus on access controls and configuration management.

4. Performance-Security Balance¶

Optimization:

Security controls that don't degrade user experience
Performance testing including security features
Right-sizing security investments based on risk
Graceful degradation under attack
User experience monitoring

Trade-off Management:

Risk-based decisions about security vs. performance
A/B testing security features for impact
Clear escalation for security-performance conflicts
Business context in security decisions

5. Customer Impact Assessment¶

During Security Events:

Rapid determination of customer data exposure
Clear internal and external communication
Regulatory notification requirements
Customer self-service tools for status checking
Transparent incident communication

Continuous Assessment:

Customer-facing security metrics
Third-party security attestations
Regular penetration testing
Bug bounty programs
Public transparency reports

Success Indicators¶

Indicator	Description	Target
Mean Time to Detect (MTTD)	Average time to identify security incidents	<15 minutes
Mean Time to Contain (MTTC)	Average time to stop incident spread	<1 hour
Mean Time to Recover (MTTR)	Average time to restore normal operations	<4 hours
Monitoring Coverage	Percentage of production systems with security monitoring	>95%
False Positive Rate	Security alerts that don't require action	<10%
Customer Impact	Percentage of incidents affecting customers	Minimize
Incident Response Readiness	Percentage of playbooks tested in last 6 months	100%

Implementation by Strategic Position¶

Visionaries (Simple + High Readiness)¶

Cloud-native monitoring and alerting
Serverless security monitoring
Automated incident response with runbooks
Modern observability platforms

Leaders (Complex + High Readiness)¶

Enterprise SIEM and SOAR platforms
Multi-cloud security monitoring
Advanced threat hunting capabilities
Comprehensive incident response coordination

Niche Players (Simple + Low Readiness)¶

Basic monitoring with cloud provider tools
Manual incident response procedures
Focus on critical system monitoring first
Gradual automation of common responses

Challengers (Complex + Low Readiness)¶

Pragmatic monitoring prioritization
Hybrid manual/automated response
Risk-based system monitoring (critical first)
Incremental observability improvements

Strategic Investments That Scale¶

Automated Response Capabilities¶

Self-Healing Systems:

Automated remediation for known issues
Canary deployment rollback automation
Automated scaling under DDoS
Self-service customer security tools

Runbook Automation:

Codified incident response procedures
Automated evidence collection
Orchestrated response actions
Continuous runbook testing

Observability Platforms¶

Unified Monitoring:

Security, performance, and reliability metrics in one place
Correlation across multiple data sources
Machine learning for anomaly detection
Developer-friendly interfaces

Common Pitfalls¶

Anti-Patterns to Avoid

Alert Fatigue: Too many alerts lead to ignored critical events

Security Theater: Monitoring without effective response capabilities

Over-Collection: Logging everything without clear use cases creates noise

Siloed Tools: Separate security and operations monitoring prevents correlation

Reactive-Only: No proactive threat hunting or vulnerability management

Quick Start Checklist¶

For organizations starting runtime stewardship:

[ ] Week 1: Enable basic security monitoring for production systems
[ ] Week 2: Create initial incident response playbook for most likely scenarios
[ ] Week 3: Implement automated alerting for critical security events
[ ] Month 2: Conduct first tabletop incident response exercise
[ ] Month 3: Deploy data encryption at rest for sensitive data
[ ] Quarter 2: Implement access management and audit logging
[ ] Quarter 3: Establish monitoring coverage metrics and improvement plan
[ ] Quarter 4: Conduct full incident response simulation with post-mortem

Next Steps¶

Continue to Third-Party Stewardship Back to Process Stewardship

Third-Party Stewardship¶

The Integration Ecosystem¶

Modern software factories rarely operate in isolation—they integrate with cloud providers, monitoring services, development tools, and business platforms. Third-party stewardship addresses the security implications of these operational dependencies.

Core Responsibility¶

Managing security risks from integrated services, platforms, and vendors throughout their operational lifecycle.

Beyond Supply Chain

While Supply Chain Stewardship focuses on dependencies incorporated into your software, Third-Party Stewardship addresses operational services and platforms that support your software factory.

Key Focus Areas¶

1. Integration Security Risk Management¶

Risk Assessment:

Security evaluation before integration
Data flow mapping and classification
Access scope and permission analysis
Vendor security posture assessment
Ongoing risk monitoring

Integration Patterns:

API security and authentication
Service-to-service encryption
Least-privilege access controls
Network segmentation where appropriate
Regular security review of integrations

Common Third-Party Integrations

Cloud Providers: AWS, GCP, Azure
Development Tools: GitHub, GitLab, CI/CD platforms
Monitoring/Observability: Datadog, New Relic, Splunk
Business Tools: Slack, Google Workspace, Salesforce
Security Tools: SIEM, vulnerability scanners, identity providers

2. Shared Responsibility Model Clarity¶

Responsibility Boundaries:

Clear documentation of who secures what
Regular validation of assumptions
Training on shared responsibility
Audit of actual vs. documented responsibilities
Incident response coordination procedures

Common Shared Responsibility Areas:

Cloud Infrastructure: Provider secures physical layer, you secure workloads
SaaS Applications: Provider secures application, you secure access and data
Platform Services: Provider secures platform, you secure usage and configuration
Identity Providers: Provider secures authentication, you secure authorization

Shared Responsibility Failures

Many security incidents result from misunderstandings about responsibility boundaries. Document and validate assumptions regularly.

3. Service Provider Security Monitoring¶

Ongoing Assessment:

Vendor security posture tracking
Compliance certification monitoring
Security incident notification requirements
Regular vendor security reviews
Third-party audit rights and execution

Vendor Communication:

Established security contacts
Incident notification procedures
Change management communication
Security improvement collaboration
Escalation paths for security issues

4. Contingency Planning¶

Service Failure Preparation:

Business continuity plans for critical services
Data portability and backup strategies
Alternative provider evaluation
Failover and recovery procedures
Regular testing of contingency plans

Vendor Security Incident Response:

Coordinated incident response procedures
Customer data protection protocols
Communication templates and responsibilities
Recovery procedures and validation
Post-incident review processes

5. Contract and SLA Security Requirements¶

Contractual Protections:

Security requirements in vendor contracts
Data protection and privacy clauses
Incident notification SLAs
Audit rights and compliance requirements
Termination and data return procedures

SLA Monitoring:

Security SLA tracking and reporting
Performance against security commitments
Escalation for SLA violations
Regular SLA review and updates

Success Indicators¶

Indicator	Description	Target
Integration Assessment Coverage	Percentage of third-party integrations with security assessment	100% of critical integrations
Shared Responsibility Validation	Frequency of shared responsibility model review	Quarterly
Vendor Security Review Completion	Percentage of critical vendors reviewed annually	100%
Contingency Plan Testing	Critical service contingency plans tested	Annually minimum
Contract Compliance	Vendor adherence to security contract requirements	>95%
Incident Coordination Time	Time to coordinate response with vendor during incident	<2 hours

Implementation by Strategic Position¶

Visionaries (Simple + High Readiness)¶

Cloud-native service integrations with built-in security
Automated vendor security monitoring
Policy-as-code for integration governance
Modern identity and access management

Leaders (Complex + High Readiness)¶

Enterprise vendor risk management platforms
Comprehensive third-party security orchestration
Cross-organization integration policies
Advanced vendor security scorecards

Niche Players (Simple + Low Readiness)¶

Basic vendor security questionnaires
Manual integration documentation
Spreadsheet-based vendor tracking
Focus on critical vendor relationships first

Challengers (Complex + Low Readiness)¶

Pragmatic vendor prioritization (critical first)
Hybrid manual/automated assessment
Gradual integration security improvements
Leverage existing procurement infrastructure

Strategic Investments That Scale¶

Vendor Risk Management Platform¶

Centralized Oversight:

Single source of truth for vendor relationships
Automated vendor security assessment
Risk scoring and trending
Integration with procurement systems
Continuous monitoring capabilities

Integration Security Patterns¶

Reusable Security Controls:

Pre-approved integration patterns
Security-vetted service catalogs
Template contracts with security requirements
Standardized authentication and authorization
Automated security validation

Common Pitfalls¶

Anti-Patterns to Avoid

Set-and-Forget Assessments: Initial vendor review without ongoing monitoring

Security Questionnaire Theater: Relying solely on vendor self-assessment

Shadow IT: Unmanaged third-party integrations circumventing security review

Unclear Responsibility: Assumptions about shared responsibility without validation

No Contingency Planning: Single points of failure without backup plans

Quick Start Checklist¶

For organizations starting third-party stewardship:

[ ] Week 1: Inventory all third-party services and integrations
[ ] Week 2: Identify critical vendors requiring immediate security review
[ ] Week 3: Document shared responsibility assumptions for critical services
[ ] Month 2: Conduct security assessments for top 5 critical vendors
[ ] Month 3: Establish vendor security incident notification procedures
[ ] Quarter 2: Develop contingency plans for single points of failure
[ ] Quarter 3: Implement vendor security review cadence
[ ] Quarter 4: Test contingency plans for critical service failures

Next Steps¶

Continue to Continuous Learning Back to Runtime Stewardship

Continuous Learning¶

The Evolution Imperative¶

The security landscape continuously evolves through new threats, technologies, and organizational changes. Continuous learning isn't optional—it's the difference between adapting to new challenges and becoming increasingly vulnerable over time.

Core Responsibility¶

Evolving security practices based on experience, incidents, and changing threat landscape while building organizational security capability.

Learning Culture

Organizations with strong continuous learning cultures treat security incidents as learning opportunities rather than failures, enabling faster adaptation and more resilient systems.

Key Focus Areas¶

1. Risk State Monitoring and Trend Analysis¶

Continuous Risk Assessment:

Regular scanning and vulnerability assessment
Threat intelligence integration
Attack surface monitoring
Risk trend analysis over time
Predictive risk modeling where possible

Actionable Intelligence:

Contextualized threat intelligence
Industry-specific threat patterns
Emerging attack techniques
Vulnerability trend analysis
Strategic risk indicators

Predictive Insights

Moving from reactive ("We got breached") to proactive ("This attack pattern is trending in our industry, let's harden defenses now")

2. Feedback Loop Optimization¶

Systematic Process Improvement:

Metrics that drive learning
Regular retrospectives on security processes
Developer and stakeholder feedback collection
A/B testing of security controls
Continuous iteration based on data

Fast Feedback Cycles:

Real-time security validation in development
Rapid incident feedback to engineering teams
Quick iterations on security tooling
Developer-friendly security metrics
Clear signals of what's working vs. what isn't

3. Incident Post-Mortems and Lessons Learned¶

Blameless Post-Mortems:

Focus on system improvements, not individual blame
Psychological safety in incident review
Root cause analysis (technical and organizational)
Clear action items with ownership
Tracking of improvement implementation

Lessons Learned Integration:

Documented incident patterns
Process improvements from incidents
Training materials updated with real examples
Runbook improvements based on actual incidents
Cross-team knowledge sharing

Blameless Culture Philosophy

"When people are held accountable for outcomes but not given the authority to change the system that produces those outcomes, you get fear instead of learning." - Focus on systemic improvements.

Cross-Functional Collaboration:

Security champions programs
Regular security training and awareness
Lunch-and-learn sessions
Internal security newsletters
Collaborative security documentation

Team Development:

Individual growth plans
Skill development opportunities
Conference attendance and knowledge sharing
Internal certification programs
Mentorship and pair programming for security

5. Industry Best Practice Adoption¶

External Learning:

Participation in security communities
Monitoring of industry security trends
Peer organization collaboration
Research paper review and application
Vendor product evaluation

Customization for Context:

Adapting industry practices to organizational reality
Avoiding "best practice" dogma
Testing before broad adoption
Measuring impact of new practices
Iterating based on results

Success Indicators¶

Indicator	Description	Target
Post-Mortem Completion Rate	Percentage of incidents with completed post-mortems	100% for significant incidents
Action Item Implementation	Percentage of post-mortem action items completed within SLA	>80%
Training Participation	Percentage of team members completing security training	>90% annually
Knowledge Sharing Frequency	Regular security knowledge sharing sessions	Monthly minimum
Feedback Loop Speed	Time from incident to process improvement	<30 days
Security Champion Engagement	Active security champions across organization	1 per 10-15 engineers

Implementation by Strategic Position¶

Visionaries (Simple + High Readiness)¶

Modern learning management systems
Automated feedback collection
Rapid experimentation with new security practices
Strong developer-security collaboration culture

Leaders (Complex + High Readiness)¶

Enterprise learning and development programs
Cross-organization knowledge sharing platforms
Advanced security training and certification programs
Comprehensive lessons learned databases

Niche Players (Simple + Low Readiness)¶

Basic incident documentation and review
Simple knowledge sharing (team meetings, wikis)
Focus on learning from own incidents first
Gradual formalization of learning processes

Challengers (Complex + Low Readiness)¶

Pragmatic incident review processes
Focus on highest-impact learnings
Targeted training for critical roles
Incremental culture change toward blameless post-mortems

Strategic Investments That Scale¶

Blameless Culture Development¶

Psychological Safety:

Leadership modeling of blameless inquiry
Reward system for surfacing problems early
Clear distinction between human error and negligence
Post-mortem facilitation training
Regular reinforcement of cultural values

Systemic Thinking:

Root cause analysis focusing on system weaknesses
Process improvements over individual accountability
Automation to prevent human error
Design for failure resilience
Continuous capability development

Knowledge Management Systems¶

Centralized Knowledge Base:

Searchable security documentation
Runbooks and playbooks
Incident history and learnings
Architectural decision records
Training materials and resources

Automated Knowledge Capture:

Incident data automatically captured
Metrics dashboards for trend analysis
Integration with communication tools
AI-powered knowledge recommendations
Continuous documentation updates

Common Pitfalls¶

Anti-Patterns to Avoid

Blame Culture: Punishing mistakes prevents surfacing of problems and learning

No Follow-Through: Post-mortems without action item implementation

Learning Theater: Training checkboxes without actual skill development

Not Invented Here: Rejecting external best practices without evaluation

Analysis Paralysis: Endless planning without experimentation and iteration

Quick Start Checklist¶

For organizations starting continuous learning stewardship:

[ ] Week 1: Establish blameless post-mortem policy and template
[ ] Week 2: Schedule first security knowledge sharing session
[ ] Week 3: Create initial security documentation repository
[ ] Month 2: Conduct first blameless post-mortem for recent incident
[ ] Month 3: Launch security champions pilot program
[ ] Quarter 2: Implement regular security training program
[ ] Quarter 3: Establish metrics for tracking continuous improvement
[ ] Quarter 4: Review and iterate on learning culture based on feedback

Next Steps¶

You've now completed all five universal stewardship responsibilities. The next section explores how to assess your organization's strategic position to determine the optimal implementation approach.

Continue to Strategic Positioning Back to Third-Party Stewardship

Strategic Positioning

Two-Axis Positioning Model¶

Understanding Your Strategic Starting Point¶

Rather than using traditional maturity models that assume linear progression, this framework positions software factories on two independent dimensions that determine your optimal security approach.

Why Not Maturity Models?

Traditional security maturity models imply everyone should follow the same path. SF² recognizes that a 10-person startup with modern cloud infrastructure shouldn't implement security the same way as a 5,000-person enterprise with legacy systems—even if both need strong security.

The Strategic Positioning Framework¶

Organizations can be assessed along two critical axes:

Operational Complexity Axis (What You Manage)¶

Simple Operations: - Single or few teams - Basic processes - Straightforward compliance - Limited interdependencies - Centralized decision-making

Complex Operations: - Multiple teams/organizations - Sophisticated processes - Multi-jurisdictional compliance - Extensive service interdependencies - Distributed decision-making

Operational Readiness Axis (How You Operate)¶

Lower Readiness: - Manual processes - Legacy infrastructure - Limited automation - Tribal knowledge - Reactive operations

Higher Readiness: - Automated pipelines - Modern infrastructure - API-driven operations - Documented processes - Proactive operations

The Four Strategic Positions¶

These two axes create four distinct strategic positions, each with different security approaches:

Visionaries (Simple + High Readiness)¶

Characteristics: - Small teams with modern technology stack - Cloud-native infrastructure - Automated from inception - DevOps/Platform engineering culture - Fast iteration and experimentation

Security Approach: Enable security through modern tooling and self-service capabilities

Strategic Focus: Leverage technology advantages while building organizational scale

Typical Organizations: - Modern startups (post-Series A) - Cloud-native SaaS companies - Platform teams in larger organizations

Visionaries in Action

A 15-person SaaS startup running on AWS with full CI/CD automation, infrastructure-as-code, and comprehensive observability. They can implement policy-as-code and automated security testing from day one.

Leaders (Complex + High Readiness)¶

Characteristics: - Large-scale operations - Sophisticated DevOps practices - Comprehensive observability - Enterprise processes - Continuous learning culture

Security Approach: Orchestrate enterprise security architecture with continuous learning

Strategic Focus: Optimize security operations at enterprise scale while maintaining innovation

Typical Organizations: - Cloud-native enterprises - Modern financial services - Advanced SaaS companies - Tech giants

Leaders in Action

A 2,000-person organization with mature platform engineering, comprehensive automation, and sophisticated security orchestration. They build internal security platforms that enable hundreds of engineers.

Niche Players (Simple + Low Readiness)¶

Characteristics: - Small-scale operations - Legacy systems - Manual processes - Limited automation - Constrained resources

Security Approach: Focus on operational readiness foundations while managing essential security controls

Strategic Focus: Build operational capabilities while maintaining security coverage

Typical Organizations: - Early-stage startups - Small businesses - Non-tech companies with limited IT - Organizations in regulated industries with legacy systems

Niche Players in Action

A 20-person company with legacy infrastructure, manual deployments, and limited security tooling. They focus on basic security hygiene and gradual automation while managing business growth.

Challengers (Complex + Low Readiness)¶

Characteristics: - Large scale with legacy constraints - Technical debt - Mixed manual/automated processes - Organizational complexity - Transformation in progress

Security Approach: Pragmatic security within constraints while enabling gradual modernization

Strategic Focus: Balance current operational demands with strategic modernization investments

Typical Organizations: - Traditional enterprises undergoing digital transformation - Financial institutions with legacy infrastructure - Healthcare organizations - Government agencies

Challengers in Action

A 5,000-person enterprise with 20+ year-old systems, mixed infrastructure (on-prem + cloud), and security teams managing both legacy and modern systems. They implement hybrid security approaches while gradually modernizing.

Assessing Your Position¶

Use these questions to determine your organization's position:

Operational Complexity Assessment¶

Question	Simple	Complex
How many teams/organizations?	1-3 teams	10+ teams
Process sophistication?	Basic workflows	Enterprise processes
Compliance scope?	Single jurisdiction	Multi-jurisdictional
Service interdependencies?	Few/simple	Extensive/complex
Decision-making?	Centralized	Distributed

Operational Readiness Assessment¶

Question	Lower Readiness	Higher Readiness
Deployment process?	Manual	Fully automated
Infrastructure?	Legacy/on-prem	Cloud-native/hybrid
Documentation?	Tribal knowledge	Comprehensive docs
Observability?	Limited/reactive	Comprehensive/proactive
Change velocity?	Weeks/months	Hours/days

Why This Matters for Security¶

Your strategic position determines:

Resource Allocation: What security investments make sense
Implementation Approach: How to roll out security capabilities
Timeline Expectations: How fast you can transform
Tool Selection: Which security tools fit your operational reality
Success Metrics: What good looks like for your organization

Common Mistake

Implementing Leaders-level security programs in a Challengers or Niche Players organization often leads to: - Failed tooling implementations - Frustrated security and development teams - Wasted budget on capabilities you can't operationalize - Security becoming a bottleneck instead of enabler

Strategic Movement Paths¶

Most organizations benefit from moving toward the Leaders position, but the path depends on your starting point:

Movement Strategies¶

Current Position	Optimal Path	Primary Investments	Timeline	Success Factors
Niche Players → Visionaries	Infrastructure modernization	Cloud platforms, DevOps toolchains, security automation	12-18 months	High (single axis movement)
Niche Players → Challengers	Complexity scaling	Team expansion, process sophistication, compliance capabilities	18-24 months	Moderate (scaling without readiness)
Visionaries → Leaders	Complexity scaling	Enterprise platforms, governance, multi-team coordination	24-36 months	High (readiness enables scaling)
Challengers → Leaders	Modernization while scaling	Hybrid solutions, change management, technical debt remediation	36-48 months	Moderate (dual transformation)
Challengers → Niche Players	Simplification	System consolidation, technical debt reduction, process streamlining	18-30 months	Low (major organizational change required)

Executive Insight

The Challengers → Leaders path is the most common but also the most challenging. It requires simultaneous modernization and scaling—transforming operations while maintaining business continuity.

Using Position to Guide Security Strategy¶

Your position determines specific security implementation approaches:

For Visionaries: - Leverage cloud-native security services - Implement policy-as-code from inception - Build security into platform capabilities - Enable developer self-service

For Leaders: - Orchestrate enterprise security architecture - Build internal security platforms - Optimize at scale with automation - Continuous security improvement programs

For Niche Players: - Focus on foundational security controls - Manual but systematic approaches - Gradual capability building - Leverage managed security services

For Challengers: - Pragmatic hybrid security approaches - Risk-based prioritization (critical systems first) - Incremental modernization - Balance legacy and modern security controls

Next Steps¶

Now that you understand strategic positioning, explore the specific characteristics and recommended approaches for each position:

Explore Strategic Positions in Detail Learn About Movement Paths

Back to Universal Stewardship

Four Strategic Positions¶

Understanding Where You Are Determines What You Should Do¶

The two-axis positioning model creates four distinct strategic positions. Each position faces different security challenges and requires fundamentally different approaches to scaling security capabilities.

Critical Insight: There is no single "best" security approach. The optimal strategy depends entirely on your organizational positioning. A Visionaries organization that implements security like Leaders will create unnecessary complexity. A Challengers organization that tries to operate like Visionaries will fail to address operational realities.

The Four Strategic Positions¶

Visionaries: Simple Operations + High Readiness¶

Who You Are: - Small teams (typically under 50 engineers) - Cloud-native infrastructure from inception - Automated CI/CD pipelines and modern DevOps practices - API-driven operations and infrastructure-as-code - Minimal legacy technical debt

Your Security Approach: Enable security through modern tooling and self-service capabilities. Leverage your technology advantages rather than building processes that assume operational constraints you don't have.

Strategic Focus: Build security automation from day one—don't create manual processes you'll need to replace in 18 months. Your high operational readiness makes automation achievable now, and your simple operations mean you won't face enterprise coordination overhead.

Key Investment Priorities:

Automated Supply Chain Security: Dependency scanning and update automation with minimal manual intervention
Pipeline-Native Security: Security checks integrated directly into CI/CD with immediate developer feedback
Self-Service Security Capabilities: Cloud platform security features that "just work" without security team involvement
Observability-First Runtime Security: Cloud-native monitoring with automated alerting and incident response

Common Pitfalls to Avoid:

Don't Build for Future Complexity

Risk: Implementing enterprise-scale security architecture "because we'll need it eventually"

Symptoms: Multi-week security design reviews, approval workflows for two-person teams, committee decision-making

Solution: Build for your current reality. Add complexity only when your operational complexity actually increases.

Success Indicators:

6 Months: Automated dependency scanning covers 95%+ of codebases, security checks integrated in all pipelines with <5 minute feedback loops
12 Months: Zero manual security reviews for standard deployments, developers resolve 80%+ security issues without security team involvement
24 Months: Security automation enables 3-5x growth without proportional security team expansion

Movement Path: As you grow, you'll naturally add operational complexity. Your challenge is maintaining high operational readiness while scaling—transition to Leaders rather than falling into the Challengers trap of adding complexity faster than capability.

See Visionaries Implementation Guide

Leaders: Complex Operations + High Readiness¶

Who You Are: - Large-scale operations (100+ engineers, multiple teams) - Sophisticated DevOps and platform engineering practices - Comprehensive observability and automation across the enterprise - Mature change management and incident response processes - Strong engineering culture with continuous learning focus

Your Security Approach: Orchestrate enterprise security architecture with integrated learning culture. Enable security at scale through platform engineering and federated security champions.

Strategic Focus: Optimize security operations at enterprise scale while maintaining innovation velocity. Your advantage is operational sophistication—use it to embed security into engineering platforms rather than building centralized security bottlenecks.

Key Investment Priorities:

Security Platform Engineering: Self-service security capabilities available across all teams and products
Federated Security Champions: Distributed security expertise within engineering teams with central guidance
Enterprise Architecture Integration: Security embedded in platform decisions and organizational standards
Continuous Security Intelligence: Automated threat detection with predictive insights and proactive response
Cultural Scaling Mechanisms: Learning from incidents and scaling security knowledge across the organization

Common Pitfalls to Avoid:

The Coordination Overhead Trap

Risk: Security program becomes a bottleneck due to enterprise coordination requirements

Symptoms: Multi-week security architecture reviews, declining developer satisfaction, increasing workarounds

Solution: Federate security decision-making to engineering teams with clear guardrails. Centralize platform capabilities, not every security decision.

Success Indicators:

6 Months: Security platform adoption across 70%+ of teams, measurable reduction in security review wait times
12 Months: Security champions program active in all major teams, 60%+ of security issues resolved without central team involvement
24 Months: Security capabilities scale automatically with organizational growth, security becomes competitive advantage

Movement Path: Stay in Leaders by continuously evolving security capabilities to match organizational scale. Falling into Challengers happens when operational readiness can't keep pace with complexity growth—maintain platform investment velocity.

See Leaders Implementation Guide

Niche Players: Simple Operations + Lower Readiness¶

Who You Are: - Small teams with limited resources - Legacy systems or manual deployment processes - Limited automation and observability - Straightforward product or service offering - Often resource-constrained or bootstrapped

Your Security Approach: Focus on operational readiness foundations while managing essential security controls. Accept manual security processes initially—but invest strategically in readiness improvements that enable future automation.

Strategic Focus: Build operational capabilities systematically while maintaining security coverage. Your simple operations mean you can afford some manual processes temporarily—use this breathing room to invest in readiness infrastructure.

Key Investment Priorities:

Critical Supply Chain Controls: Basic dependency scanning and critical vulnerability management
Foundational Readiness Infrastructure: CI/CD basics, infrastructure documentation, change management fundamentals
Essential Runtime Monitoring: Basic production monitoring and incident response capabilities
Process Documentation: Record what works to enable eventual automation and knowledge transfer

Common Pitfalls to Avoid:

The Permanent Manual Process Trap

Risk: Treating manual processes as acceptable long-term state rather than temporary necessity

Symptoms: "This is how we've always done it," no automation roadmap, resistance to process changes

Solution: Be explicit that manual processes are temporary. Document current state as foundation for future automation. Invest consistently in readiness improvements.

Success Indicators:

6 Months: Critical dependencies monitored, basic CI/CD pipeline operational, documented security processes
12 Months: 30-50% automation of security checks, measurable reduction in manual security work
18-24 Months: Operational readiness sufficient to support automation investments, movement toward Visionaries position

Movement Path: Move toward Visionaries by investing in operational readiness. This single-axis movement is achievable—prioritize cloud migration, DevOps tooling, and automation infrastructure over adding operational complexity.

See Niche Players Implementation Guide

Challengers: Complex Operations + Lower Readiness¶

Who You Are: - Large-scale operations with legacy constraints - Significant technical debt and mixed infrastructure (legacy + modern) - Manual processes coexist with automated systems - Complex compliance and regulatory requirements - Multiple organizational changes or acquisitions

Your Security Approach: Pragmatic security within constraints while enabling gradual modernization. Accept that full transformation takes 3-5 years—don't promise 12-month miracles.

Strategic Focus: Balance current operational demands with strategic modernization investments. Your complexity prevents rapid transformation, but your scale justifies investment in foundational improvements.

Key Investment Priorities:

Pragmatic Supply Chain Controls: Risk-based approach given limitations—focus on critical paths and crown jewels
Hybrid Security Architecture: Solutions that work across legacy and modern systems without requiring full modernization
Strategic Technical Debt Reduction: Systematic elimination of highest-risk legacy constraints enabling future automation
Change Management and Communication: Organizational alignment on multi-year transformation reality and sequencing
Quick Wins for Credibility: Visible improvements that build organizational confidence in long-term transformation

Common Pitfalls to Avoid:

The Two-Axis Transformation Trap

Risk: Attempting simultaneous complexity reduction AND readiness improvement—highest failure risk

Symptoms: Aggressive transformation timelines, simultaneous re-platforming and process overhauls, widespread disruption

Solution: Sequence changes carefully. Typically, invest in readiness first (Challengers → Leaders path) to enable automation at scale. Accept 36-48 month timeline.

Success Indicators:

12 Months: Hybrid security solutions operational, critical technical debt reduction projects started, transformation roadmap with executive buy-in
24 Months: Measurable automation improvements in high-value areas, improved operational readiness metrics, cultural momentum toward transformation
36-48 Months: Substantial progress toward Leaders position, security increasingly enabling business rather than constraining it

Movement Path: Most Challengers should move toward Leaders by investing in operational readiness while managing existing complexity. This is difficult but achievable with sustained executive support and realistic timelines. Attempting to simplify operations (Challengers → Niche Players) rarely succeeds—requires major business restructuring.

See Challengers Implementation Guide

Position Assessment Tool¶

Use these questions to confirm your strategic position:

Operational Complexity Assessment¶

Question	Simple	Complex
Team Scale	Single team or few coordinated teams	Multiple teams across organizational boundaries
Service Interdependencies	Straightforward dependencies	Extensive service mesh with complex interactions
Compliance Scope	Single jurisdiction, basic requirements	Multi-jurisdictional, sector-specific regulations
Customer Impact	Single product or limited services	Enterprise platform or multiple customer-facing systems

Operational Readiness Assessment¶

Question	Lower Readiness	Higher Readiness
Deployment Automation	Manual or partially automated deployments	Fully automated CI/CD with infrastructure-as-code
Infrastructure	Legacy systems, manual configuration	Cloud-native or hybrid with API-driven management
Observability	Limited monitoring, reactive incident response	Comprehensive observability with proactive alerting
Process Documentation	Tribal knowledge, inconsistent documentation	Well-documented, standardized processes

Your Position: Plot your answers to identify which quadrant best describes your current state.

Strategic Position and Investment Strategy¶

Your strategic position determines your optimal approach to the investment portfolio:

Position	BAU Approach	Scaling Investment Focus	Timeline to ROI
Visionaries	Minimal BAU burden initially	Automation-first from inception	6-12 months
Leaders	Systematic BAU constraint	Platform capabilities at scale	12-18 months
Niche Players	Manageable manual BAU	Foundational readiness infrastructure	18-24 months
Challengers	High BAU burden requiring constraint	Strategic debt reduction + readiness	24-48 months

Common Position Misidentification¶

Startup Founder Self-Assessment: "We're obviously Niche Players—we're small and scrappy!"

Reality Check: If you're cloud-native with automated deployments, you're Visionaries. Your small size is simple operations, but your modern stack is high readiness. Don't build manual processes just because you're small.

Established Enterprise Self-Assessment: "We're Leaders—we have mature security programs!"

Reality Check: If you're running significant legacy infrastructure with manual deployments, you're Challengers regardless of security team size. Your complexity is high, but operational readiness is constrained by technical debt.

High-Growth Startup Self-Assessment: "We're Visionaries scaling successfully!"

Reality Check: If you're adding teams faster than automation, you're moving toward Challengers (high complexity, decreasing readiness). Maintain readiness investments or you'll face the two-axis transformation trap.

Next Steps¶

Confirm Your Position: Use the assessment tools above to validate your quadrant
Review Movement Paths: Understand how to transition strategically
Read Your Implementation Guide: Apply position-specific guidance from 06-implementation/
Evaluate Contextual Modifiers: Understand how your specific situation affects implementation

Back to Two-Axis Model Continue to Movement Paths

Edit this page

Strategic Movement Paths¶

How Organizations Transition Between Positions¶

Understanding your current strategic position is only the first step. Most organizations benefit from moving toward the Leaders position (Complex + High Readiness), but the path you take determines your likelihood of success.

The Transformation Reality

Quadrant transitions are organizational transformations, not technology projects. Single-axis movements (changing one dimension) take 12-24 months and have high success probability. Dual-axis transformations (changing both dimensions simultaneously) take 36-48 months and carry significant failure risk.

The Strategic Movement Framework¶

The Goal Position: Leaders¶

Why Leaders: The Leaders quadrant combines enterprise-scale capabilities with operational excellence. Organizations in this position achieve:

Security capabilities that scale automatically with organizational growth
Developer experience improvements that increase rather than constrain velocity
Platform approaches that enable innovation while maintaining security controls
Cultural integration where security is a competitive advantage, not a constraint

Reality Check: Not every organization needs to reach Leaders immediately. Your optimal target depends on your business trajectory and organizational change capacity.

Six Strategic Movement Paths¶

From → To	Movement Type	Timeline	Success Probability	Strategic Guidance
Niche Players → Visionaries	Single-axis (Readiness ↑)	12-18 months	High ⭐⭐⭐⭐	Operational Readiness Path
Niche Players → Challengers	Single-axis (Complexity ↑)	18-24 months	Moderate ⭐⭐	Complexity Scaling Path
Visionaries → Leaders	Single-axis (Complexity ↑)	24-36 months	High ⭐⭐⭐⭐	Enterprise Scaling Path
Challengers → Niche Players	Single-axis (Complexity ↓)	18-30 months	Low ⭐	Simplification Path
Challengers → Leaders	Dual-axis	36-48 months	Moderate ⭐⭐	Dual Transformation Path
Leaders → Leaders	Position Maintenance	Ongoing	High ⭐⭐⭐⭐	Excellence Sustainment

Path 1: Niche Players → Visionaries (Operational Readiness)¶

Movement Type: Single-axis (Increasing Operational Readiness)

Timeline: 12-18 months

Success Probability: High ⭐⭐⭐⭐

When to Choose This Path¶

Yes, if: - Your business remains relatively simple (single team or product focus) - You have budget/appetite for infrastructure modernization - Legacy technical debt is constraining your business velocity - You want to enable future automation before complexity increases

No, if: - You're simultaneously scaling teams and organizational complexity rapidly - Legacy systems have significant customer dependencies requiring careful migration - Business model requires immediate complexity scaling

Key Investment Priorities¶

Cloud Migration: Move from on-premises or manual infrastructure to cloud platforms
CI/CD Implementation: Automated build, test, and deployment pipelines
Infrastructure as Code: Terraform, CloudFormation, or similar tooling
Observability Foundation: Centralized logging, metrics, and monitoring
Security Automation: Dependency scanning, SAST/DAST integration into pipelines

Sequencing Strategy¶

Months 1-6: Foundation - [ ] Cloud platform selection and initial migration planning - [ ] Basic CI/CD pipeline for new services or non-critical systems - [ ] Observability platform implementation with critical system coverage - [ ] Team training on cloud-native practices and DevOps principles

Months 7-12: Acceleration - [ ] Expand CI/CD coverage to 70%+ of systems - [ ] Infrastructure as Code for new deployments - [ ] Security tooling integrated into pipelines with automated feedback - [ ] Legacy system migration planning with risk assessment

Months 13-18: Completion - [ ] 90%+ systems on modern infrastructure - [ ] Automated security scanning comprehensive - [ ] Manual deployment processes eliminated for standard changes - [ ] Team operating with cloud-native mindset and capabilities

Success Indicators¶

Technical: Deployment frequency increases 5-10x, infrastructure provisioning time reduced from days to minutes
Security: Vulnerability detection moves from quarterly to continuous, dependency management automated
Cultural: Team enthusiasm for new capabilities, reduced resistance to process changes

Common Pitfalls¶

The 'Lift and Shift' Trap

Risk: Moving legacy systems to cloud without architectural modernization—you get cloud bills without operational readiness benefits

Solution: Modernize incrementally. Start with new services cloud-native, migrate legacy strategically with re-architecture where beneficial

Path 2: Niche Players → Challengers (Complexity Scaling)¶

Movement Type: Single-axis (Increasing Operational Complexity)

Timeline: 18-24 months

Success Probability: Moderate ⭐⭐

When to Choose This Path¶

Yes, if: - Business growth requires rapid team scaling and organizational complexity - Market opportunity demands enterprise features and capabilities - Investment in operational readiness infrastructure isn't immediately feasible

No, if: - You can afford to invest in readiness first (Niche → Visionaries → Leaders is better) - Current manual processes are already creating business constraints - Team has capacity to focus on foundational improvements

Strategic Warning¶

This path creates technical debt. You're adding complexity (multiple teams, enterprise features, regulatory requirements) without corresponding automation infrastructure. Plan for eventual Challengers → Leaders transformation requiring 36-48 months.

Key Investment Priorities¶

Team Scaling: Hiring and organizational structure for multiple teams
Process Sophistication: Coordination mechanisms, change management, incident response
Compliance Capabilities: Regulatory frameworks, audit readiness, documentation
Manual Security Scale: Security team growth to match increased operational complexity

Success Indicators¶

Business: Successfully serving enterprise customers, meeting regulatory requirements
Operational: Multiple teams operating with coordination processes
Security: Maintaining security coverage despite increased complexity

Recommended Next Steps¶

Plan immediately for Challengers → Leaders transformation. Don't stay in Challengers long-term—it's unsustainable.

Path 3: Visionaries → Leaders (Enterprise Scaling)¶

Movement Type: Single-axis (Increasing Operational Complexity)

Timeline: 24-36 months

Success Probability: High ⭐⭐⭐⭐

When to Choose This Path¶

Optimal scenario for sustainable growth: You're scaling complexity while maintaining operational readiness—the high-success transformation path.

Key Investment Priorities¶

Platform Engineering: Self-service security capabilities for multiple teams
Federated Security Model: Security champions program with central guidance
Enterprise Architecture: Standardized patterns and reusable security components
Organizational Design: Matrix management, cross-functional coordination
Cultural Scaling: Learning culture that scales with organizational growth

Sequencing Strategy¶

Months 1-12: Platform Foundation - [ ] Security platform vision and initial capabilities - [ ] Security champions program launch in 2-3 pilot teams - [ ] Enterprise architecture patterns documented - [ ] Cross-team coordination mechanisms established

Months 13-24: Scaling - [ ] Platform capabilities covering 50%+ of common security needs - [ ] Security champions in all major teams - [ ] Federated decision-making with clear guardrails - [ ] Organizational structure supporting scale

Months 25-36: Optimization - [ ] Platform capabilities comprehensive and self-service - [ ] Security embedded in engineering culture - [ ] Continuous improvement processes mature - [ ] Security as competitive advantage realized

Success Indicators¶

Platform Adoption: 70%+ of teams using self-service security capabilities
Developer Satisfaction: Measurable improvement in security experience scores
Security Outcomes: Capabilities scale automatically with team growth
Cultural: Security champions viewed as career development opportunities

Path 4: Challengers → Niche Players (Simplification)¶

Movement Type: Single-axis (Reducing Operational Complexity)

Timeline: 18-30 months

Success Probability: Low ⭐

Strategic Reality Check¶

This is the hardest path and rarely succeeds. Reducing operational complexity typically requires:

Major business restructuring or product simplification
Customer migration from complex to simple offerings
Organizational downsizing or significant reorganization
Market repositioning from enterprise to SMB or niche focus

When This Might Be Necessary¶

Business pivot from enterprise to SMB market
Divestiture or spin-off creating smaller organization
Post-acquisition rationalization eliminating complexity
Strategic decision to focus on core simplified offering

Why This Usually Fails¶

Customer Commitments: Existing customers expect continued enterprise capabilities
Revenue Dependency: Complex offerings often generate significant revenue
Organizational Resistance: Teams resist simplification seen as "scaling back"
Market Perception: Simplification can be viewed as retreat or failure

Alternative: Consider Challengers → Leaders Instead¶

Most Challengers should invest in operational readiness rather than attempting to reduce complexity. The Challengers → Leaders path is difficult but more achievable than organizational simplification.

Path 5: Challengers → Leaders (Dual Transformation)¶

Movement Type: Dual-axis (Increasing Readiness while Managing Complexity)

Timeline: 36-48 months

Success Probability: Moderate ⭐⭐

When to Choose This Path¶

Reality: Most Challengers organizations must take this path—you can't simplify complexity, so you must modernize operations.

The Challenge¶

You're simultaneously: - Managing high operational complexity (multiple teams, legacy systems, enterprise requirements) - Improving operational readiness (automation, cloud migration, technical debt reduction)

This requires sustained executive support, significant investment, and realistic timeline expectations.

Critical Success Factors¶

Executive Sponsorship: Sustained leadership commitment over 3-5 years
Realistic Timelines: Accept 36-48 months; don't promise 12-month miracles
Hybrid Solutions: Technology that works with legacy AND modern systems
Strategic Debt Reduction: Systematic elimination of highest-risk constraints
Quick Wins: Visible improvements that maintain organizational momentum

Sequencing Strategy¶

Phase 1 (Months 1-12): Stabilize and Plan - [ ] Comprehensive assessment of current state and transformation requirements - [ ] Hybrid security architecture supporting legacy and modern systems - [ ] Quick wins demonstrating transformation value and building confidence - [ ] Executive alignment on 36-48 month realistic timeline - [ ] Transformation roadmap with clear milestones and success metrics

Phase 2 (Months 13-24): Foundation Building - [ ] Critical technical debt reduction enabling future automation - [ ] Modern platforms deployed alongside legacy systems - [ ] Automation pilots in high-value areas demonstrating ROI - [ ] Cultural initiatives building transformation momentum - [ ] Change management reducing organizational resistance

Phase 3 (Months 25-36): Acceleration - [ ] Significant automation coverage with measurable benefits - [ ] Legacy system migration or modernization showing progress - [ ] Platform capabilities emerging enabling self-service - [ ] Organizational capability development sustaining transformation

Phase 4 (Months 37-48): Optimization - [ ] Leaders-level capabilities operational across organization - [ ] Legacy constraints substantially eliminated or managed - [ ] Security automation enabling business velocity - [ ] Competitive advantage realization from transformation

Common Pitfalls¶

The Aggressive Timeline Trap

Risk: Promising 12-18 month transformation when 36-48 months is realistic

Symptoms: Burnout, partial implementations abandoned, organizational skepticism about security competence

Solution: Be honest about timelines. Under-promise and over-deliver. Secure executive commitment for realistic multi-year transformation.

Success Indicators¶

12 Months: Hybrid solutions operational, transformation roadmap with executive buy-in, visible quick wins
24 Months: Measurable automation improvements, improved readiness metrics, cultural momentum
36-48 Months: Substantial Leaders-level capabilities, security enabling rather than constraining business

Path 6: Maintaining Leaders Position¶

Movement Type: Position Maintenance and Continuous Evolution

Timeline: Ongoing

Success Probability: High ⭐⭐⭐⭐ (with continued investment)

The Challenge¶

You're not done. The Leaders position requires continuous investment to maintain as: - Organizational complexity continues evolving - Technology platforms change and require adaptation - Threat landscape shifts requiring capability updates - Competitive pressure demands ongoing innovation

Key Investment Priorities¶

Platform Evolution: Continuous improvement of security self-service capabilities
Cultural Sustainment: Learning culture maintenance and psychological safety preservation
Innovation Integration: Incorporating new technologies and security practices
Competitive Advantage: Translating security capabilities into market differentiation
Talent Development: Growing security and engineering capability across organization

Common Pitfall: Complacency¶

The 'We've Arrived' Trap

Risk: Treating Leaders position as destination rather than ongoing commitment

Symptoms: Platform investment declining, manual processes creeping back, cultural erosion

Solution: Continuous investment in capabilities matching organizational evolution. Falling from Leaders to Challengers happens when readiness can't keep pace with complexity growth.

Movement Path Selection Guide¶

Decision Framework¶

Use these questions to select your optimal path:

1. What is your current position? - Accurately assess using strategic positions assessment tool

2. What is your business trajectory? - Remaining simple vs scaling complexity - Revenue growth supporting transformation investment - Market pressures requiring rapid change

3. What is your organizational change capacity? - Executive sponsorship sustainability over multi-year timeline - Team capacity for transformation alongside operational demands - Cultural readiness for significant change

4. What are your critical constraints? - Budget availability for transformation investment - Technical debt severity limiting automation potential - Regulatory requirements affecting technology choices

Recommended Paths by Situation¶

High-growth startup (Niche Players): - Best: Niche → Visionaries (12-18 months) → Leaders (24-36 months) - Avoid: Niche → Challengers (creates technical debt requiring later remediation)

Established enterprise with legacy (Challengers): - Best: Challengers → Leaders (36-48 months) - Avoid: Attempting Challengers → Niche Players (usually fails)

Cloud-native startup scaling (Visionaries): - Best: Visionaries → Leaders (24-36 months) - Maintain: High operational readiness during complexity scaling

Industry leader (Leaders): - Best: Leaders → Leaders (continuous evolution) - Avoid: Complacency leading to readiness degradation

Next Steps¶

Confirm Your Current Position: Use strategic positions assessment
Select Your Target Path: Based on business trajectory and change capacity
Review Contextual Modifiers: Understand how your specific constraints affect timeline
Read Your Implementation Guide: Position-specific guidance in 06-implementation/
Develop Transformation Roadmap: Use sequencing strategies above to create your plan

Back to Strategic Positions Continue to Investment Portfolio

Edit this page

Investment Portfolio

Investment Portfolio Framework¶

The Scaling Challenge Every Security Leader Encounters¶

Picture this scenario: Your development teams want faster security reviews. Customer success needs immediate responses to security questionnaires. Compliance requires detailed audit preparations. Meanwhile, a critical vulnerability just dropped, and your CEO is asking about your incident response plan.

Sound familiar? You've hit the scaling crisis—the inevitable moment when demand for security services grows exponentially while your team capacity grows linearly.

The Inflection Point

Most security leaders respond to scaling challenges by hiring more people and working longer hours. While this provides temporary relief, it becomes increasingly difficult to sustain long-term and doesn't address the fundamental capability gap.

A Different Approach¶

Past a certain point, the solution isn't necessarily doing more security work—it's deliberately constraining some activities while investing in capabilities that reduce future manual effort. This section shows you how to make this strategic shift while maintaining security outcomes.

The BAU Scaling Crisis¶

The Capability Gap Reality¶

The BAU scaling crisis isn't just a resource problem—it's a capability mismatch. When adversaries automate attacks at internet scale while defenders remain manual, no amount of hiring closes the gap.

The Structural Mismatch: - Manual defender processes: Quarterly vulnerability scans, manual asset discovery, individual security reviews - Scaled adversary automation: Continuous probing, automated reconnaissance, industrial-scale exploitation

This structural mismatch—manual defender processes versus scaled adversary automation—makes the crisis inevitable.

Exponential Demand Growth¶

As software factories grow, traditional security activities face a mathematical scaling challenge:

Security reviews increase with feature velocity
Threat modeling requests scale with system complexity
Customer security inquiries grow with customer base expansion
Incident response requirements increase with system surface area
Compliance activities expand with regulatory scope

Meanwhile, security team capacity grows linearly at best. Hiring requires time and creates temporary productivity reduction during onboarding. Communication overhead increases with team size.

The Inflection Point

Organizations reach a point where demand for BAU security services exceeds sustainable capacity, creating constraints on both security effectiveness and business velocity.

Strategic Choice Point¶

Organizations approaching this inflection point can choose between different resource allocation strategies:

Traditional Scaling Approach ❌¶

Hire additional security personnel for manual work
Attempt to maintain current service levels across all requests
Build custom solutions for individual use cases
Maintain primarily reactive security posture

Result: Temporary relief followed by recurring capacity crises

Strategic Scaling Approach ✅¶

Deliberately constrain capacity for some BAU activities
Develop automation and self-service capabilities
Create standardized approaches for common security needs
Shift toward proactive, scalable security architecture

Result: Sustainable security that improves with scale

Investment Portfolio Categories¶

BAU Activities (Constrain)¶

Characteristics: - Manual work that scales with growth - Security reviews, threat modeling, incident response - Customer security questionnaires - Individual risk assessments

Evaluation Criteria: - Operational necessity - Customer impact - Constraint sustainability

Resource Allocation: Deliberately limited capacity post-crisis

Expected ROI: Immediate but unsustainable scaling

Constraining BAU Strategically

Constraint doesn't mean abandonment. It means providing self-service alternatives, automation, and clear prioritization criteria.

Scaling Investments (Prioritize)¶

Characteristics: - Capabilities that reduce manual effort exponentially - Automation platforms, self-service capabilities, policy-as-code - Developer security platforms - Continuous security validation

Evaluation Criteria: - Manual effort reduction potential - Developer experience improvement - Time to value - Cultural alignment - Organizational change requirements

Resource Allocation: Primary investment focus past crisis point

Expected ROI: 6-18 months with compound returns

Scaling Investment Examples

Paved Roads: Secure templates that eliminate security review needs
Self-Service Platforms: Automated environments with security baked in
Policy-as-Code: Automated compliance validation
Automated Dependency Management: Continuous monitoring without manual effort

Platform Effects (Multiply)¶

Characteristics: - Benefits both internal and customer software factories - Security capabilities that create multiplicative value - Open-source security tools - Security-as-a-service offerings

Evaluation Criteria: - Internal business case + multiplicative customer value - Competitive differentiation - Market amplification potential

Resource Allocation: Enhancement to scaling investments

Expected ROI: 12-24 months with market amplification

Investment Evaluation Framework¶

When evaluating security investments, consider these criteria:

Criteria	Description	Why It Matters
Manual Effort Reduction	Will this eliminate repetitive work permanently?	Primary driver of sustainable scaling
Developer Experience Impact	Does this reduce security friction or create new complexity?	Critical for organizational adoption
Time to Value	How quickly will benefits become measurable?	Affects organizational confidence
Cultural Alignment	Does this support learning culture and psychological safety?	Determines long-term sustainability
Organizational Change Requirements	What adoption challenges should we anticipate?	Affects implementation success probability
Adversary Economics	Does this make attacks more expensive or time-consuming?	Security succeeds when it shifts cost-benefit against attackers

Designing Security Capabilities That Compound¶

The "Catch and Store" Principle¶

The most sustainable security investments don't just solve immediate problems—they capture organizational effort and store it in reusable capabilities that serve future needs without additional manual work.

Renewable Energy Analogy

Like renewable energy systems that provide ongoing value after initial investment, effective scaling investments become self-sustaining and increasingly valuable over time.

Examples of Compound Capabilities:

Paved Roads: - Secure templates and baselines that engineers reuse without security review - Each use provides security value without marginal security team effort - Templates improve based on lessons learned

Self-Service Platforms: - Automated environments and policy-as-code - Eliminates recurring security review requests - Scales to thousands of deployments without proportional security team growth

Automated Dependency Management: - Continuous monitoring without manual scanning - Automated vulnerability detection and remediation - Improves security posture while reducing security team workload

Security-Quality Integration: - Process improvements that serve both goals simultaneously - Single investment, dual benefits - Reinforcing improvements over time

Avoid Energy-Consuming Tools

Some security tools create new maintenance burdens without proportional value. Favor investments that become more valuable and less demanding over time—capabilities that store energy rather than consume it.

BAU Constraint Strategy by Organizational Stage¶

Organizational Stage	BAU Constraint Approach	Communication Strategy	Alternative Provision
Pre-Crisis	Maintain current service levels	"We're investing in better capabilities"	Gradual self-service introduction
Crisis Point	Strategic capacity limits	"We're shifting to sustainable scaling"	Clear self-service alternatives
Post-Crisis	Systematic constraint with alternatives	"Improved capabilities now available"	Comprehensive self-service platform

Financial Model Considerations¶

Security leaders must work within inherited financial constraints while building toward more strategic integration:

Cost Center Context¶

Reality: Security viewed as overhead to minimize

Strategy: Focus on compliance cost avoidance and operational efficiency

Communication: Emphasize business risk reduction and efficiency gains

Investment Opportunities: Crisis events create windows for scaling investment approval

Shared Services Context¶

Reality: Security funded through chargeback model

Strategy: Develop strong business cases emphasizing internal customer satisfaction

Communication: Highlight operational improvements that reduce business friction

Investment Opportunities: Service level improvements and efficiency gains

R&D Integration Context¶

Reality: Security integrated into product development budget

Strategy: Frame security investments as competitive advantages

Communication: Measure success through business outcomes rather than security-specific metrics

Investment Opportunities: Product security capabilities that differentiate in market

Strategic Conversation Template¶

When proposing the shift from traditional to strategic scaling:

Executive Communication

"We've identified that our current security approach may become a business constraint as we continue to scale. Rather than only adding capacity through hiring—which provides temporary relief—we recommend investing in capabilities that reduce manual effort requirements permanently.

This approach can improve both security outcomes and business velocity over time. The initial investment will create capabilities that compound: each use provides security value without proportional security team effort.

We'll measure success through developer satisfaction, security coverage, and time-to-market improvements—demonstrating that security enables rather than constrains business growth."

Implementation Roadmap¶

Quarter 1: Assessment and Planning - Measure current BAU demand and capacity - Identify scaling investment opportunities - Assess developer pain points - Build business case for strategic shift

Quarter 2: Pilot Scaling Investments - Select highest-impact scaling investment - Implement pilot with small team - Measure manual effort reduction - Collect developer feedback

Quarter 3: Constrain BAU + Scale Alternatives - Introduce strategic BAU constraints - Provide self-service alternatives - Communicate clearly about transition - Monitor adoption and satisfaction

Quarter 4: Iterate and Expand - Review pilot results and iterate - Expand successful scaling investments - Build compound capabilities - Demonstrate ROI to stakeholders

Next Steps¶

Explore specific aspects of the investment portfolio framework:

BAU vs Scaling Investments Platform Effects Evaluation Criteria

Back to Strategic Positioning

BAU vs Scaling Investments¶

The Inevitable Choice Every Security Leader Faces¶

Every security leader eventually confronts the same mathematical reality: demand for security services grows exponentially while team capacity grows linearly. This creates an inflection point where traditional approaches become unsustainable.

The Traditional Response: Hire more security professionals, work longer hours, accept growing backlogs.

The Strategic Response: Deliberately constrain some activities to invest in capabilities that reduce future manual effort.

This section explains how to make this strategic shift while maintaining security outcomes.

The BAU Scaling Crisis¶

The Mathematical Reality¶

As software factories grow, traditional security activities face a scaling challenge that hiring alone cannot solve:

Demand Grows Exponentially: - Security review requests increase with feature velocity (more teams = more requests) - Threat modeling needs scale with system complexity (more services = more models) - Customer security inquiries grow with customer base (enterprise customers demand more) - Incident response requirements increase with system surface area (more systems = more incidents) - Compliance activities expand with regulatory scope (new markets = new requirements)

Capacity Grows Linearly: - Hiring requires time (3-6 months per role typically) - Onboarding creates temporary productivity reduction (new hires require training) - Communication overhead increases with team size (coordination costs rise) - Maintaining quality becomes challenging during rapid scaling (standards slip under pressure)

The Inflection Point: Organizations reach a point where demand for BAU (Business-as-Usual) security services exceeds sustainable capacity, creating constraints on both security effectiveness and business velocity.

The Capability Gap: Beyond Just Capacity¶

The BAU scaling crisis isn't only about volume—it's about a fundamental capability mismatch between manual defenders and automated adversaries.

The Adversary Capability Shift: In recent years, adversaries evolved from targeted reconnaissance to automated discovery at internet scale. Using techniques inspired by bug bounty programs and internet-wide scanning, attackers can now:

Discover unknown assets (forgotten servers, shadow IT, unmanaged dependencies) faster than organizations can inventory them
Exploit known vulnerabilities within hours or days of disclosure
Conduct credential stuffing at scale against thousands of targets simultaneously
Probe continuously while defenders scan quarterly

The Structural Problem: Organizations conducting quarterly vulnerability scans face adversaries who probe continuously. Manual asset discovery can't keep pace with automated reconnaissance. This isn't a resource problem that hiring solves—it's a capability mismatch that requires automation.

Critical Insight: Supply Chain as #1 Priority

Supply chain security became the #1 priority not because dependencies increased, but because adversary capability evolved. When attackers can discover your unknown assets faster than you can catalog them, supply chain security becomes existential regardless of your other security investments.

The Strategic Choice Point¶

At the scaling inflection point, organizations face two fundamentally different resource allocation strategies:

Traditional Scaling Approach (Unsustainable)¶

Strategy: Attempt to maintain current service levels through capacity increases

Typical Actions: - Hire additional security personnel for manual work - Extend working hours to cover growing demand - Build custom solutions for individual use cases - Maintain primarily reactive security posture - Accept growing backlogs as "normal"

Why This Fails: - Hiring doesn't close the capability gap against automated adversaries - Linear capacity growth can't match exponential demand growth - Custom solutions create maintenance burden without scaling benefits - Team burnout and quality degradation become inevitable - Security becomes a business constraint and bottleneck

Strategic Scaling Approach (Sustainable)¶

Strategy: Deliberately constrain capacity for some BAU activities to create investment cycles for automation and self-service capabilities

Typical Actions: - Set explicit capacity limits for manual security activities - Develop automation and self-service capabilities systematically - Create standardized approaches for common security needs - Shift toward proactive, scalable security architecture - Measure and communicate ROI from scaling investments

Why This Succeeds: - Automation closes the capability gap against scaled adversaries - Capabilities create compound returns over time - Self-service enables teams without security team growth - Developer experience improves rather than degrades - Security becomes a competitive advantage enabler

The Compound Interest Principle

Just as financial investments generate compound returns, security scaling investments create exponential value. An automation capability used 100 times costs the same to build as one used once, but delivers 100x the value. Manual security work scales linearly—each review costs the same effort.

Investment Portfolio Categories¶

Security investments fall into three categories with fundamentally different scaling characteristics:

BAU Activities (Constrain Past Crisis Point)¶

Definition: Manual work that scales linearly with organizational growth

Examples: - Manual security design reviews for each new service - Threat modeling sessions requiring security team participation - Individual incident response investigations - Customer security questionnaire responses - Ad-hoc compliance evidence collection

Characteristics: - Required for business operations (can't eliminate entirely) - Demand grows with organizational scale - Each instance requires similar effort (limited efficiency gains) - Creates capacity constraints at scale

Strategic Approach: - Pre-Crisis: Maintain current service levels while building alternatives - Crisis Point: Set explicit capacity constraints with communication strategy - Post-Crisis: Systematic constraint with clear self-service alternatives

Constraint Strategy by Position:

Position	BAU Approach	Constraint Mechanism
Visionaries	Minimal BAU burden initially	Automation-first—avoid creating manual processes
Leaders	Systematic constraint with alternatives	Self-service platform + clear escalation paths
Niche Players	Manageable manual processes	Document processes while building readiness
Challengers	High burden requiring constraint	Triage system + strategic automation pilots

Scaling Investments (Prioritize Post-Crisis)¶

Definition: Capabilities that reduce manual effort exponentially or enable self-service

Examples: - Automated dependency scanning with auto-remediation - Self-service security environment provisioning - Policy-as-code with automated enforcement - Security champions program enabling distributed expertise - Developer security training and tooling integration

Characteristics: - Initial investment required (time, money, organizational change) - Benefits compound over time (more usage = more value) - Reduces future manual effort requirements systematically - Enables organizational scaling without proportional security team growth

Evaluation Criteria:

Criterion	Why It Matters	Assessment Question
Manual Effort Reduction	Primary driver of sustainable scaling	Will this eliminate repetitive work permanently?
Developer Experience	Critical for adoption	Does this reduce security friction or create new complexity?
Time to Value	Affects organizational confidence	How quickly will benefits become measurable?
Cultural Alignment	Determines sustainability	Does this support learning culture and psychological safety?
Adversary Economics	Validates security value	Does this force attackers to more expensive approaches?

Expected ROI Timeline: 6-18 months with compound returns increasing over time

Platform Effects (Multiply)¶

Definition: Investments that benefit both your organization AND customer software factories (platform companies only)

Examples: - Security platform features customers can leverage - Open-source security tools serving broader ecosystem - Security standards that become industry practices - Shared threat intelligence benefiting community

Characteristics: - Internal business case must justify investment independently - Customer value creates additional strategic benefits - Competitive differentiation potential - Market influence and thought leadership opportunities

Evaluation: Internal benefit × customer multiplier + competitive advantage

See Also: Platform Effects for detailed guidance for platform companies

Designing Security Capabilities That Compound¶

The "Catch and Store Energy" Principle¶

The most sustainable security investments don't just solve immediate problems—they capture organizational effort and store it in reusable capabilities that serve future needs without additional manual work.

Like renewable energy systems that provide ongoing value after initial investment, effective scaling investments become self-sustaining:

Paved Roads: Secure templates and baselines that engineers reuse without security review - One-time effort: Design secure baseline architecture, document patterns - Ongoing value: Every team using the template saves 10-20 hours of security reviews - Compound effect: As templates improve based on feedback, all users benefit automatically

Self-Service Platforms: Automated environments and policy-as-code eliminating recurring requests - One-time effort: Build security environment provisioning automation - Ongoing value: Teams provision secure infrastructure in minutes instead of days - Compound effect: Platform improvements benefit all users without additional security team effort

Automated Dependency Management: Continuous monitoring without manual intervention - One-time effort: Integrate automated dependency scanning and update tools - Ongoing value: Vulnerabilities detected and remediated automatically - Compound effect: Coverage expands automatically as new services are built

Security-Quality Integration: Process improvements serving both objectives simultaneously - One-time effort: Integrate security checks into CI/CD quality gates - Ongoing value: Security and quality issues detected together in development - Compound effect: Quality improvements enhance security, security improvements enhance quality

What to Avoid: Security Tools That Consume Energy¶

The Maintenance Burden Trap

Some security tools create ongoing maintenance costs that exceed their security value. Avoid investments that:

Require continuous manual tuning to remain effective
Generate high false-positive rates demanding constant triage
Need specialized expertise that creates key-person dependencies
Don't integrate with existing development workflows
Create new manual processes rather than automating existing ones

Favor investments that: - Become more valuable and less demanding over time - Store organizational knowledge in reusable form - Enable self-service without security team involvement - Integrate seamlessly into existing workflows - Improve developer experience while improving security

BAU Constraint Communication Strategy¶

Constraining BAU activities requires clear communication to maintain organizational support and developer relationships.

Communication by Organizational Stage¶

Pre-Crisis (Building Alternatives):

Message: "We're investing in improved capabilities that will provide faster, more consistent security support."

Actions: - Maintain current service levels while building alternatives - Gradual introduction of self-service options - Measure baseline metrics for later comparison - Build organizational confidence in new approaches

Crisis Point (Implementing Constraints):

Message: "We've reached a scaling inflection point. To ensure sustainable security support, we're shifting from manual processes to self-service capabilities. Here's what's changing, here are the alternatives, and here's the timeline for improved capabilities."

Actions: - Set explicit capacity limits with clear justification - Provide immediate self-service alternatives (even if basic) - Establish escalation paths for critical needs - Regular updates on scaling investment progress

Example Communication:

"Our security review process has reached capacity constraints. Starting next quarter, we're implementing a self-service security baseline that will enable most teams to deploy securely without security review wait times. For projects outside this baseline, we'll use a triage process prioritizing business-critical initiatives. We expect this transition to take 6 months, after which your experience will significantly improve."

Post-Crisis (Systematic Operations):

Message: "Improved self-service capabilities are now available. Most teams can now [specific capability] without security team involvement, and we've measured [specific improvement metric]."

Actions: - Demonstrate ROI realization from scaling investments - Showcase developer experience improvements - Adjust capacity constraints based on capability maturity - Continuous improvement of self-service platforms

Financial Model Considerations¶

Security leaders operate within inherited financial contexts that affect investment strategies:

Cost Center Context¶

Constraints: Security viewed as overhead, budget scrutiny, ROI skepticism

Strategy: - Focus on compliance cost avoidance (failed audits cost money) - Emphasize operational efficiency (automation reduces labor costs) - Use crisis events as opportunities for scaling investment approval - Frame investments as risk reduction with quantifiable business impact

Conversation Template:

"Our current security approach will become a business constraint as we scale. Rather than only adding capacity through hiring—which provides temporary relief at increasing cost—we recommend investing in capabilities that reduce manual effort requirements permanently. This approach improves both security outcomes and business velocity while managing cost growth."

Shared Services Context¶

Constraints: Internal customer satisfaction, operational metrics, service level expectations

Strategy: - Develop business cases emphasizing internal customer satisfaction - Measure and communicate developer experience improvements - Show operational improvements reducing business friction - Position security as enabling faster, safer delivery

Conversation Template:

"Our internal customers currently wait an average of 5 days for security reviews. By investing in self-service security baselines, we can reduce this to under 1 hour for 70% of projects while improving security consistency. This enables faster delivery without compromising security outcomes."

R&D Integration Context¶

Constraints: Security competes with feature development for resources and attention

Strategy: - Frame security investments as competitive advantages - Measure success through business outcomes, not security metrics - Demonstrate security capabilities enabling business opportunities - Position security as accelerating time-to-market for secure products

Conversation Template:

"Security automation isn't just about managing risk—it's about enabling our engineers to move faster with confidence. By investing in security platforms, we can support 3x growth without proportional security team expansion while improving both security posture and delivery velocity."

Success Metrics for Investment Shifts¶

Track these metrics to validate your BAU constraint and scaling investment strategy:

Leading Indicators (Early Signals)¶

Scaling investment velocity: Projects started, adoption rates, developer feedback
Alternative capability usage: Self-service adoption rates, platform utilization
Developer satisfaction trends: Survey scores, friction reports, voluntary participation
Investment pipeline health: Approved projects, executive support, resource allocation

Lagging Indicators (Results)¶

Manual effort reduction: Hours saved per activity type, capacity freed for strategic work
ROI realization: Measurable benefits vs investment costs, compound return evidence
Security outcomes: Vulnerability detection rates, incident response times, risk posture improvements
Business velocity: Time-to-market improvements, deployment frequency increases, developer productivity gains

Next Steps¶

Assess Your Position: Are you pre-crisis, at crisis point, or post-crisis in your scaling journey?
Evaluate Current Portfolio: Catalog BAU activities and identify scaling investment opportunities
Review Evaluation Criteria: Systematic framework for prioritizing investments
Understand Platform Effects: Additional considerations for platform companies
Develop Communication Strategy: Prepare stakeholder messaging for investment shifts

Back to Portfolio Framework Continue to Platform Effects

Edit this page

Platform Effects¶

Multiplicative Value for Platform Companies¶

Platform companies—organizations that provide capabilities to other software factories—have unique opportunities to create value that extends beyond their immediate organization. However, these opportunities come with important constraints and strategic considerations.

Critical Principle: Platform effects should serve as investment multipliers, not primary drivers. The internal business case must work first.

Who This Section Is For¶

This guidance applies specifically to:

Platform Companies: Organizations whose products serve other software factories - Cloud platforms (AWS, Azure, GCP, etc.) - Development tools and CI/CD platforms (GitLab, GitHub, CircleCI, etc.) - Security platforms and tools (vulnerability scanners, SIEM, etc.) - Developer productivity platforms (observability, monitoring, etc.) - Infrastructure and container platforms (Kubernetes, Docker, etc.)

Not applicable to: - End-user application companies (even large ones) - Internal platform teams serving only their own organization - Security vendors selling traditional enterprise software

If you're not a platform company serving other software factories, focus on BAU vs Scaling and Evaluation Criteria instead.

The Platform Effects Principle¶

Primary Responsibility: Solve Your Own Problems First¶

Non-Negotiable Foundation: Security investments must first make business sense for your direct needs. Platform effects are enhancement factors, not justifications.

Why This Matters: - Your security team's primary responsibility is securing your software factory - Platform features that don't solve your internal problems create maintenance burden - Customer value without internal value is unsustainable - Failed internal implementations can't become successful external products

The Platform Distraction Trap

Risk: Building security features for customers that your own organization doesn't use or value

Symptoms: Platform features your internal teams avoid, customer requests driving roadmap over internal needs, security theater for market positioning

Solution: Eat your own dog food. If your security team won't use it internally, don't build it for customers.

Multiplicative Opportunity: When Internal and Customer Value Align¶

The Strategic Multiplier: When security investments that solve your internal problems also benefit customer software factories, this creates additional value justifying:

Higher investment levels than internal-only business case supports
Faster implementation timelines with cross-functional priority
Different prioritization relative to competing initiatives
Market differentiation and competitive advantage opportunities

Example: Automated dependency scanning - Internal value: Reduces your security team's manual effort, improves your supply chain security posture - Customer value: Enables your customers to secure their supply chains using your platform - Platform effect: 10,000 customers using your feature = 10,000x the security value created - Competitive advantage: Security capability differentiating your platform from competitors

Platform Investment Prioritization Framework¶

Use this systematic framework to evaluate security investments when you're a platform company:

Evaluation Dimensions¶

Dimension	Assessment Criteria	Weight	Strategic Implication
Direct Security Benefit	Does this solve our internal security problems?	Primary	Business case foundation—must pass threshold independently
Multiplicative Customer Value	Does this create additional customer value?	Enhancement	Multiplier on internal business case, breaks ties between competing investments
Competitive Differentiation	Does this create defensible advantages?	Strategic	Market positioning, pricing power, customer acquisition/retention
Industry Influence	Does this position us as thought leaders?	Market	Long-term market development, standard adoption, ecosystem benefits

Decision Matrix¶

Strong Internal + Strong Customer Value (Highest Priority): - Example: Automated vulnerability management solving your supply chain problems that customers can leverage - Priority: Accelerate implementation, allocate cross-functional resources, market aggressively - Timeline Impact: May justify 30-50% faster implementation than internal-only business case - Investment Level: Can justify 2-3x higher investment than internal-only features

Strong Internal + Weak Customer Value (Standard Priority): - Example: Internal compliance automation specific to your regulatory environment - Priority: Standard internal security investment evaluation using evaluation criteria - Timeline Impact: Normal implementation sequencing - Investment Level: Internal business case justification required

Weak Internal + Strong Customer Value (Avoid): - Example: Security features customers request but your team doesn't use - Priority: Decline or deprioritize—likely maintenance burden without sustainability - Warning: High risk of poor execution, customer disappointment, wasted investment

Weak Internal + Weak Customer Value (Reject): - Example: Security theater features for marketing purposes - Priority: Hard reject—diverts resources from valuable work - Risk: Damages credibility with both internal teams and customers

Customer Zero Insights and Strategic Weighting¶

The "Customer Zero" Advantage¶

Platform companies often serve as sophisticated users of their own products, providing unique insights into security challenges and solutions. Your internal security pain often represents market opportunities.

Adversary Evolution Insights: When your platform company experiences security challenges that mirror broader industry shifts, these Customer Zero insights carry additional strategic weight.

Example: Modern Supply Chain Security

Your platform company discovers that: - Automated dependency scanning significantly reduces your manual security effort - Your security team's productivity improves 3x with automated vulnerability management - Unknown dependency discovery becomes systemat

ic rather than reactive

Strategic Insight: If this internal pain point reflects modern adversary capabilities (automated discovery at scale), it likely represents a market opportunity affecting thousands of customer software factories facing the same capability gap.

Customer Zero Cost Impact Assessment¶

When evaluating internal security pain points, weight them by total organizational impact including the Customer Zero amplification factor:

Cost Category	Internal Cost Assessment	Customer Zero Multiplier	Strategic Priority
Direct Incident Costs	Breach response, system downtime, recovery efforts	1x (internal impact)	High
Security Research/Bug Bounty	External researcher rewards, program costs	2x (customer trust impact)	Medium
Vulnerability Management	Discovery, assessment, patching cycles	1.5x (operational efficiency)	High
Business Disruption	Customer communication, support escalation, sales impact	3x (customer experience amplification)	High
Engineering Cycles	Feature development diverted to security firefighting	2x (opportunity cost amplification)	Medium
Customer Trust Erosion	Churn risk, sales pipeline impact, competitive disadvantage	5x (platform company trust multiplier)	Critical

Strategic Application: If a security issue category costs your organization $5M annually across these factors, and Customer Zero insights suggest this affects thousands of customers similarly, the platform investment justification becomes compelling:

Internal problem: $5M annual cost
Customer impact: Thousands of factories facing similar issues
Platform solution value: Addresses market need while solving internal problem
Competitive differentiation: Security capability competitors may lack

Implementation Prioritization for Platform Companies¶

When you've identified a security investment with both internal and customer value, use this sequencing approach:

Phase 1: Internal Implementation and Validation (Critical)¶

Objective: Solve your own problem first, learn from real usage

Activities: - Implement security capability solving your internal team's pain - Use internally with realistic production workloads - Measure actual impact on your security team's effectiveness - Iterate based on internal feedback and usage patterns

Success Criteria: - Your security team actively uses and values the capability - Measurable improvement in internal security metrics - Positive feedback from internal stakeholders - Sustainable operational model established

Timeline: 3-6 months typically

Phase 2: Customer Zero Learnings Integration¶

Objective: Refine based on internal experience before customer exposure

Activities: - Document lessons learned from internal implementation - Identify operational challenges and edge cases discovered - Develop customer-facing documentation based on internal experience - Create support and troubleshooting guidance from real issues

Success Criteria: - Clear understanding of capability limitations and tradeoffs - Documented best practices from internal usage - Realistic customer expectations established - Support burden manageable based on internal experience

Timeline: 1-2 months typically

Phase 3: Limited Customer Beta (If Customer Value Validated)¶

Objective: Validate customer value hypothesis with friendly customers

Activities: - Select 3-5 sophisticated customers for beta program - Provide hands-on support during initial adoption - Measure customer outcomes and gather detailed feedback - Validate that customer experience matches your internal experience

Success Criteria: - Customers achieve measurable security improvements - Feedback validates value hypothesis - Support burden matches predictions - Customers actively use capability (not just enable it)

Timeline: 3-6 months typically

Phase 4: General Availability (Only If Beta Succeeds)¶

Objective: Scale capability to broader customer base

Activities: - Polish customer experience based on beta feedback - Scale support infrastructure for broader adoption - Market capability emphasizing customer outcomes - Monitor adoption and iterate based on usage patterns

Success Criteria: - Adoption rates meet targets - Customer satisfaction scores strong - Support burden sustainable - Competitive differentiation realized

Security as Competitive Advantage¶

Market Differentiation Questions¶

Evaluate whether security investments create defensible competitive advantages:

1. Does this capability create defensible competitive advantages? - Is this difficult for competitors to replicate? - Does this build on unique platform strengths? - Can this become customer-facing product value driving adoption?

2. Does this enable market expansion? - Does improved security enable entry into regulated industries? - Can this support enterprise customer requirements? - Does this address blockers in sales pipeline?

3. How does this compare to competitor security offerings? - Do competitors offer similar capabilities? - Is your implementation meaningfully better? - Can customers easily switch to competitors?

4. What is the thought leadership opportunity? - Can this position you as security innovation leader? - Does this enable industry standard or best practice development? - Will this attract top security talent to your organization?

Communication Strategy for Platform Companies¶

Critical Balance: Platform companies must clearly communicate that platform security capabilities serve dual purposes—protecting the platform while enabling customer security—without creating unrealistic expectations about security responsibility transfer.

The Shared Responsibility Clarity Requirement

Platform security features enhance customer capabilities but don't transfer security accountability. Customers remain responsible for their security decisions and implementations.

Good Communication Example:

"Our automated dependency scanning capability protects our platform and is available to help you secure your software factory. This tool provides vulnerability detection and remediation guidance, but you remain responsible for reviewing findings and making security decisions appropriate to your risk tolerance and operational context."

Bad Communication Example (Avoid):

"Our platform handles your security, so you don't need to worry about vulnerabilities." [Implies accountability transfer]

Platform Effect Measurement¶

Track these metrics to validate platform effects investment strategy:

Internal Metrics (Primary)¶

Internal security improvement: Your team's security posture improvements
Internal operational efficiency: Reduced manual effort, faster incident response
Internal developer satisfaction: Your engineers' experience with security capabilities

Customer Metrics (Secondary)¶

Customer adoption rates: Percentage of customers using platform security capabilities
Customer security outcomes: Measurable improvements in customer security postures
Customer satisfaction scores: NPS or similar for security features
Customer retention impact: Reduced churn attributable to security capabilities

Competitive Metrics (Strategic)¶

Market differentiation: Customer acquisition attributable to security capabilities
Thought leadership indicators: Conference talks, standards adoption, media coverage
Talent attraction: Security engineer recruiting success, employer brand strength

Common Platform Company Pitfalls¶

Pitfall 1: Building for Customers Before Internal Validation¶

Symptom: Platform features your own security team doesn't use

Consequence: Poor quality, unsustainable support burden, customer disappointment

Solution: Always implement internally first, validate value, then consider customer availability

Pitfall 2: Overselling Security Responsibility Transfer¶

Symptom: Marketing language implying customers can "let platform handle security"

Consequence: Customer misunderstanding, blame when security issues occur, legal/liability concerns

Solution: Clear shared responsibility communication, explicit customer accountability

Pitfall 3: Platform Effect as Primary Driver¶

Symptom: Investments justified by customer value without internal business case

Consequence: Unsustainable features, internal team resistance, maintenance burden

Solution: Require internal business case independence, use customer value as multiplier only

Pitfall 4: Ignoring Customer Zero Insights¶

Symptom: Internal security pain dismissed as "just our problem"

Consequence: Missed market opportunities, competitive disadvantage

Solution: Systematic assessment whether internal pain represents broader market need

Next Steps¶

Assess Platform Company Status: Confirm whether platform effects guidance applies to your organization
Evaluate Current Investments: Review security investments through platform effects lens
Prioritize Internal Value: Ensure internal business cases are solid before considering customer value
Review Evaluation Criteria: Systematic framework works for all security investments
Consider Customer Zero Insights: Identify internal pain representing market opportunities

Back to BAU vs Scaling Continue to Evaluation Criteria

Edit this page

Investment Evaluation Criteria¶

Systematic Framework for Prioritizing Security Investments¶

Security leaders face overwhelming numbers of potential investments—automation projects, tooling purchases, process improvements, platform capabilities. Without systematic evaluation criteria, investment decisions become reactive or driven by whoever shouts loudest.

This framework provides objective criteria for evaluating and prioritizing scaling investments.

When to Use This Framework¶

Appropriate for: - Scaling investments (automation, self-service, platform capabilities) - Tool and technology selection decisions - Process improvement prioritization - Resource allocation across competing security initiatives

Not designed for: - Emergency incident response (requires immediate action) - Regulatory compliance requirements (non-discretionary) - Executive-mandated initiatives (political reality) - BAU activity triage (different evaluation model)

The Six Evaluation Criteria¶

Use these criteria to score and compare potential security investments systematically:

1. Manual Effort Reduction¶

The Question: Will this eliminate repetitive work permanently?

Why Primary: Manual effort reduction is the fundamental driver of sustainable scaling. Investments that don't reduce manual work don't solve the scaling crisis—they may improve security outcomes but won't enable organizational growth without proportional security team expansion.

Assessment Framework:

Score	Manual Effort Reduction	Annual Hours Saved	Example
5 - Exceptional	Eliminates entire category of manual work	2,000+ hours annually	Automated dependency scanning replacing manual reviews
4 - High	Reduces 70-90% of manual effort in domain	1,000-2,000 hours	Self-service environment provisioning
3 - Moderate	Reduces 40-70% of manual effort	500-1,000 hours	Automated security questionnaire responses
2 - Low	Reduces 10-40% of manual effort	100-500 hours	Partial process automation
1 - Minimal	Reduces <10% of manual effort	<100 hours	Security tool with high manual overhead

Assessment Questions: - What manual security work does this eliminate completely? - How many person-hours per month does this category consume currently? - Will benefits compound as the organization scales? - Does this create capacity for strategic work, or just shift manual effort?

Red Flags: - "This tool will help us work more efficiently" (without specific hour reduction) - Automation that requires extensive manual tuning or maintenance - Solutions that create new categories of manual work

2. Developer Experience Impact¶

The Question: Does this reduce security friction or create new complexity?

Why Critical: Scaling investments require developer adoption to deliver value. Security capabilities that degrade developer experience face resistance, workarounds, or abandonment regardless of security benefits. Developer experience is not a "nice to have"—it determines adoption success.

Assessment Framework:

Score	Developer Experience	Time Impact	Adoption Likelihood
5 - Exceptional	Dramatically improves developer workflow	Saves developers 5+ hours/week	Enthusiastic adoption, voluntary expansion
4 - High	Noticeably improves workflow	Saves 2-5 hours/week	Willing adoption, positive feedback
3 - Neutral	Minimal workflow change	±30 minutes/week	Passive acceptance, follow guidelines
2 - Moderate Friction	Some workflow disruption	Costs 1-2 hours/week	Resistance, some workarounds
1 - High Friction	Significant workflow disruption	Costs 5+ hours/week	Active resistance, widespread workarounds

Assessment Questions: - Does this integrate seamlessly into existing development workflows? - How much additional time or effort does this require from developers? - Do developers see personal benefit, or only security team benefit? - What happens when developers encounter edge cases or issues? - Is this faster/easier than current alternatives (including workarounds)?

Developer Experience Testing: - Pilot with friendly team before broad rollout - Measure time-to-first-value (how long until developers see benefits) - Track adoption voluntarily vs via mandate - Monitor for workaround creation or process avoidance

3. Time to Value¶

The Question: How quickly will benefits become measurable?

Why Important: Time to value affects organizational confidence in scaling investment strategy. Long-running projects with delayed benefits create skepticism, while quick wins build momentum and executive support. This doesn't mean always choosing fastest options—but timeline awareness is critical for communication and sequencing.

Assessment Framework:

Score	Time to Value	Measurable Benefits	Organizational Impact
5 - Immediate	<3 months to measurable impact	Quick win visible to stakeholders	Builds confidence quickly, enables next investments
4 - Fast	3-6 months to measurable impact	Benefits emerging, metrics improving	Sustains momentum, validates strategy
3 - Moderate	6-12 months to measurable impact	Significant effort before payoff	Requires sustained commitment, regular updates
2 - Slow	12-18 months to measurable impact	Long investment before returns	Requires strong executive support, milestone communication
1 - Delayed	18+ months to measurable impact	Benefits uncertain or far future	High risk of abandonment, requires exceptional justification

Assessment Questions: - What is minimum viable implementation that delivers measurable value? - Can we phase this to deliver incremental benefits? - What metrics will demonstrate value, and when can we measure them? - How do we communicate progress during implementation?

Sequencing Strategy: - Start investment portfolio with high time-to-value projects (score 4-5) - Build organizational confidence before tackling longer-term investments - Mix quick wins with strategic long-term capabilities - Communicate realistic timelines—don't over-promise to get approval

4. Cultural Alignment¶

The Question: Does this support learning culture and psychological safety?

Why Critical: Security investments succeed or fail based on organizational culture. Capabilities that punish developers, create blame dynamics, or undermine psychological safety will be resisted or circumvented regardless of security benefits. Cultural alignment isn't "soft"—it's a hard requirement for adoption success.

Assessment Framework:

Score	Cultural Alignment	Psychological Safety Impact	Learning Culture Support
5 - Exceptional	Actively builds learning culture	Enhances safety, enables experimentation	Facilitates continuous improvement, knowledge sharing
4 - High	Supports existing culture	Maintains safety, no blame creation	Enables learning opportunities
3 - Neutral	Culturally compatible	Doesn't affect safety dynamics	Neither helps nor hinders learning
2 - Friction	Cultural resistance likely	May create defensive behavior	Could limit experimentation
1 - Damaging	Undermines culture	Reduces safety, creates blame	Inhibits learning, creates fear

Assessment Questions: - Does this create opportunities for learning and improvement? - Will this tool/process be used to blame individuals for security issues? - Does this support experimentation and innovation, or constrain it? - How does this affect trust between security and engineering teams? - Does this enable self-service and autonomy, or create dependencies and gatekeeping?

Cultural Red Flags: - Tools that "catch" developers making mistakes (blame framing) - Processes that require security approval for experimentation - Metrics that rank individuals or teams on security "scores" - Automation that blocks without explanation or education - Systems that feel like surveillance rather than enablement

5. Organizational Change Requirements¶

The Question: What adoption challenges should we anticipate?

Why Important: Even technically excellent capabilities fail if organizational change requirements exceed capacity. Understanding change burden helps with sequencing (tackle easier wins first), resource planning (what support is needed), and communication strategy (how to frame the change).

Assessment Framework:

Score	Change Requirements	Adoption Difficulty	Success Requirements
5 - Minimal	Works with existing processes	Easy adoption, minimal training	Basic communication, standard rollout
4 - Low	Minor workflow adjustments	Some training required	Clear documentation, support availability
3 - Moderate	Significant workflow changes	Moderate training, practice needed	Change management, pilot programs, champions
2 - High	Major process transformation	Extensive training, culture shift	Sustained executive support, dedicated change resources
1 - Extreme	Organizational restructuring	Fundamental way-of-working change	Multi-year transformation, may require external help

Assessment Questions: - How much does this change existing ways of working? - What training or skill development does this require? - Do we have change management resources to support adoption? - What is organizational appetite for change right now? - Are there competing changes creating change saturation?

Change Management Success Factors: - Start with willing early adopters, not mandates - Provide hands-on support during initial adoption - Celebrate early successes and share learnings - Address failures constructively, iterate based on feedback - Ensure executive visible support throughout adoption

6. Adversary Economics¶

The Question: Does this force attackers to more expensive or time-consuming approaches?

Why Important: Security ultimately succeeds by making attacks economically infeasible or tactically impractical. Investments that don't affect adversary behavior may be compliance theater rather than risk reduction. Understanding adversary economics validates whether security investments actually improve security outcomes.

Assessment Framework:

Score	Adversary Impact	Attack Economics Change	Strategic Security Value
5 - Exceptional	Forces adversary pivot to different vector	Makes current attacks infeasible	Closes entire attack category
4 - High	Significantly increases attack cost/time	Requires sophisticated adversary capability	Substantially raises bar for successful attacks
3 - Moderate	Moderately increases attack difficulty	Deters opportunistic attackers	Reduces risk from common threat actors
2 - Low	Slightly increases attack effort	Minimal impact on determined adversaries	Limited practical security improvement
1 - Minimal	No meaningful adversary impact	Attacks remain economical	Compliance theater, negligible risk reduction

Assessment Questions: - Does this eliminate an attack vector completely, or just make it harder? - Do attackers need to develop new capabilities to succeed? - Does this protect against automated/scaled attacks, or only targeted efforts? - Will adversaries simply move to easier targets or different techniques? - Does this address current adversary capabilities, or historical threats?

Adversary Evolution Context:

Adversaries evolved from targeted reconnaissance to automated discovery at internet scale. Investments that address this capability gap have exceptional adversary economics impact:

Automated asset discovery (defenders find assets before attackers)
Continuous vulnerability management (close windows of exposure)
Supply chain automation (detect unknown dependencies)
Real-time threat detection (match adversary speed)

Community-Level Success: In rare cases, entire communities "win" security domains. When enough organizations implement strong controls in a domain, attackers shift entirely to other vectors because that domain becomes uneconomical. This represents the highest form of security success.

Investment Scoring and Prioritization¶

Scoring Method¶

For each potential investment, score across all six criteria (1-5 scale):

Manual Effort Reduction (weight: 2x)
Developer Experience (weight: 1.5x)
Time to Value (weight: 1x)
Cultural Alignment (weight: 1.5x)
Organizational Change (weight: 1x, reverse scored—lower is better)
Adversary Economics (weight: 2x)

Total Score Calculation:

Total = (Manual Effort × 2) + (Developer Experience × 1.5) + (Time to Value × 1) +
        (Cultural Alignment × 1.5) + ((6 - Organizational Change) × 1) + (Adversary Economics × 2)

Maximum Possible Score: 47
Minimum Possible Score: 13.5

Priority Thresholds¶

Total Score	Priority	Action
38-47	Must Do	Implement immediately, highest resource priority
30-37	Should Do	Strong business case, sequence strategically
22-29	Consider	Evaluate context, may be valuable in specific situations
13.5-21	Avoid	Poor fit, likely low ROI or high failure risk

Example Investment Evaluation¶

Proposed Investment: Automated dependency scanning with auto-remediation

Scoring: - Manual Effort Reduction: 5 (eliminates 2,000+ hours of manual reviews annually) - Developer Experience: 4 (automatic security fixes reduce developer toil) - Time to Value: 5 (measurable benefits within 8 weeks of deployment) - Cultural Alignment: 4 (enables learning, no blame dynamics) - Organizational Change: 4 (low change requirement, integrates with existing CI/CD) - Adversary Economics: 5 (addresses modern adversary capabilities, closes supply chain gaps)

Total Score: (5×2) + (4×1.5) + (5×1) + (4×1.5) + ((6-4)×1) + (5×2) = 10 + 6 + 5 + 6 + 2 + 10 = 39

Priority: Must Do (Score 39/47)

Justification: Exceptional score across all criteria. Addresses fundamental scaling challenge while improving developer experience and closing critical security gaps created by adversary evolution.

Position-Specific Evaluation Adjustments¶

Your strategic position affects criteria weighting:

Visionaries (Simple + High Readiness)¶

Adjust weights: - Increase Time to Value weight (rapid iteration preferred) - Increase Developer Experience weight (preserve innovation culture) - Decrease Organizational Change concern (high change capacity)

Prioritize: Quick-win automation, developer-centric tools, modern platform capabilities

Leaders (Complex + High Readiness)¶

Adjust weights: - Increase Adversary Economics weight (sophisticated threat model) - Increase Cultural Alignment weight (learning culture critical at scale) - Maintain balanced approach across all criteria

Prioritize: Platform capabilities, federated solutions, cultural scaling mechanisms

Niche Players (Simple + Lower Readiness)¶

Adjust weights: - Increase Organizational Change sensitivity (limited change capacity) - Prioritize readiness-building over automation breadth - Focus on foundational capabilities enabling future investments

Prioritize: Readiness infrastructure, documentation, basic automation proving value

Challengers (Complex + Lower Readiness)¶

Adjust weights: - Dramatically increase Organizational Change sensitivity (change saturation risk) - Increase Time to Value weight (need quick wins for credibility) - Focus on hybrid solutions working with legacy constraints

Prioritize: Strategic debt reduction, hybrid architecture, visible quick wins building momentum

Comparative Investment Analysis¶

Use this framework to compare competing investments:

Example Scenario: Choose between three automation investments with limited budget

Investment	Manual Effort	Dev Experience	Time to Value	Cultural	Org Change	Adversary Econ	Total Score	Priority
Dependency Scanning	5	4	5	4	4	5	39	Must Do
Security Review Automation	4	3	3	3	3	3	28	Consider
Compliance Documentation	2	2	4	3	4	1	21	Avoid

Decision: Prioritize dependency scanning—highest total score, addresses adversary evolution, exceptional ROI.

Common Evaluation Mistakes¶

Mistake 1: Optimizing for Single Criterion¶

Problem: Choosing investments based solely on one factor (usually cost or vendor relationship)

Consequence: Miss investments with exceptional overall value but moderate cost

Solution: Systematic multi-criteria evaluation, weighted scoring

Mistake 2: Ignoring Developer Experience¶

Problem: Selecting security tools security team loves but developers hate

Consequence: Poor adoption, workarounds, wasted investment

Solution: Pilot with developers first, weight developer experience appropriately

Mistake 3: Underweighting Cultural Alignment¶

Problem: Treating culture as "soft" factor, prioritizing technical capabilities

Consequence: Technically excellent solutions that fail organizationally

Solution: Recognize cultural alignment as hard requirement, not nice-to-have

Mistake 4: Chasing Vendor Hype¶

Problem: Investing based on vendor marketing rather than internal evaluation

Consequence: Tools solving problems you don't have, creating new maintenance burden

Solution: Start with your pain points, evaluate vendors against your criteria

Next Steps¶

Catalog Potential Investments: List scaling investments under consideration
Score Systematically: Evaluate each using six criteria framework
Prioritize by Position: Apply position-specific weighting adjustments
Sequence Strategically: Consider BAU vs Scaling investment timing
Review Platform Effects: Additional considerations if you're a platform company

Back to Platform Effects Continue to Contextual Modifiers

Edit this page

Contextual Modifiers

Contextual Modifiers¶

Adapting Your Strategy to Organizational Reality¶

While the core framework applies universally, six contextual factors significantly modify your implementation approach. Understanding these modifiers helps you adapt the framework to your specific organizational constraints and opportunities.

Context Matters

Two organizations in the same strategic position (e.g., both Challengers) may need different implementation approaches based on their contextual modifiers. These factors help you customize the universal framework to your reality.

The Six Contextual Modifiers¶

Modifier	Impact on Implementation	Assessment Questions
Attack Landscape Maturity	Accelerates need for automation; manual processes become existential vulnerabilities	Do attackers discover our assets before we do? Are we seeing automated reconnaissance?
Supply Chain Complexity	May require Leaders-level tools regardless of base quadrant	How many dependency tiers? Critical single vendors? Geopolitical constraints?
Regulatory Constraints	Increases BAU burden; may delay quadrant progression	Audit frequency? Technology constraints? Compliance violation risk?
Crisis Events	Can rapidly accelerate quadrant movement through organizational change	Recent major incidents? Lasting organizational changes?
Change Capacity	Affects transition speed and scaling investment success probability	Tool rollout timelines? Process disruption tolerance?
Relationship Health	Directly affects adoption velocity and scaling investment success	Proactive consultation frequency? Voluntary participation rates?

How Modifiers Work¶

Impact Levels¶

Each modifier has three impact levels that influence your implementation:

Low Impact: Minor adjustments to base quadrant approach

Moderate Impact: Significant customization needed; may advance or delay certain investments

High Impact: May require capabilities from a different quadrant or fundamentally alter implementation timeline

Modifier Interaction¶

Contextual modifiers can compound or offset each other:

Compounding Effects: - High attack landscape maturity + high supply chain complexity = Supply chain becomes urgent regardless of quadrant - Low change capacity + poor relationship health = Scaling investments will face significant adoption challenges

Offsetting Effects: - High regulatory constraints (slows down) + crisis events (speeds up) = May create windows for change during crisis response - Low change capacity + strong relationship health = Adoption challenges mitigated by trust and collaboration

Using Modifiers Strategically¶

Assessment Process¶

Evaluate Each Modifier: Use the assessment questions to determine impact level (Low/Moderate/High)
Identify Compounding Factors: Look for modifiers that reinforce each other
Spot Constraints: Understand which modifiers limit your options
Find Opportunities: Identify modifiers that could accelerate transformation

Implementation Adjustments¶

For Positive Modifiers (High relationship health, strong change capacity): - Accelerate transformation timelines - Take on more ambitious scaling investments - Experiment with advanced capabilities earlier

For Constraining Modifiers (High regulatory constraints, low change capacity): - Extend timelines and add checkpoints - Start with smaller pilots before broad rollout - Invest in change management and stakeholder alignment - Choose less disruptive implementation paths

For Crisis Modifiers (High attack landscape maturity, recent crisis events): - Prioritize security investments that address immediate threats - Use urgency to accelerate approvals and adoption - Balance rapid response with sustainable transformation

Contextual Modifier Matrix¶

Use this matrix to assess your organization:

Modifier	Low Impact	Moderate Impact	High Impact	Your Assessment
Attack Landscape	Primarily targeted attacks	Automated attacks on common vulnerabilities	Adversaries discovering assets faster than your inventory	?
Supply Chain	Standard dependencies, known vendors	Multi-tier dependencies, critical SaaS integrations	National security implications, highly regulated vendors	?
Regulatory	Standard business compliance (GDPR, privacy)	Industry-specific requirements (HIPAA, PCI-DSS, SOX)	Government/defense requirements (FedRAMP, financial regulations)	?
Crisis Events	Minor operational issues	Security incidents, compliance failures	Major breaches, business disruption	?
Change Capacity	Risk-averse culture, slow adoption	Selective pilots, gradual rollouts	Innovation culture, rapid experimentation	?
Relationship Health	Damaged security-R&D relationships	Functional but transactional	Strategic partnership collaboration	?

Strategic Examples¶

Example 1: Visionary with High Attack Landscape Maturity¶

Base Position: Visionaries (Simple + High Readiness)

Modifier Impact: High attack landscape maturity means automated adversaries despite small scale

Adjustment: Prioritize supply chain automation and continuous monitoring even earlier than typical Visionary roadmap. The capability gap created by automated adversaries requires immediate automation response.

Example 2: Challenger with Strong Relationship Health¶

Base Position: Challengers (Complex + Low Readiness)

Modifier Impact: Strong relationship health enables faster adoption despite operational constraints

Adjustment: Leverage trust to implement hybrid solutions more aggressively. Good relationships reduce friction of transformation, allowing faster progress than typical Challenger timeline.

Example 3: Leader with High Regulatory Constraints¶

Base Position: Leaders (Complex + High Readiness)

Modifier Impact: Heavy regulatory burden increases BAU workload despite strong operational capabilities

Adjustment: Factor compliance operational overhead into capacity planning. May need dedicated compliance automation investments before other scaling capabilities.

Next Steps¶

Explore each contextual modifier in detail to understand how it affects your implementation:

Attack Landscape Maturity Supply Chain Complexity Regulatory Constraints

Back to Investment Portfolio

Attack Landscape Maturity¶

The Critical Shift: From Targeted to Automated¶

Around 2017, the attack landscape fundamentally changed. Adversaries evolved from targeted reconnaissance against specific organizations to automated discovery at internet scale—sweeping billions of assets to find exploitable weaknesses.

The Automation Advantage

High attack landscape maturity means adversaries can discover your unknown assets—forgotten servers, shadow IT, unmanaged dependencies—faster than you can inventory them. This creates an existential capability gap regardless of your strategic position.

Maturity Levels¶

Low Maturity: Targeted Attacks¶

Characteristics: - Attacks require specific knowledge of your systems - Manual reconnaissance against known targets - Attacker invests time in individual organizations - Exploitation requires customization

Defender Advantage: - Manual security processes can keep pace - Quarterly assessments may be sufficient - Asset discovery matches attacker reconnaissance speed

Implementation Impact: Manual security processes remain viable

Moderate Maturity: Automated Common Vulnerabilities¶

Characteristics: - Automated scanning for known vulnerabilities - Some internet-scale reconnaissance - Exploitation of common misconfigurations - Credential stuffing at scale

Defender Challenge: - Manual processes start falling behind - Need for continuous monitoring increases - Asset inventory must be more frequent

Implementation Impact: Automation becomes important but not yet existential

High Maturity: Industrial-Scale Automation¶

Characteristics: - Bug bounty techniques applied at internet scale - Adversaries discover assets before defenders catalog them - Rapid exploitation of disclosed vulnerabilities - Automated reconnaissance of entire attack surfaces - Real-time vulnerability weaponization

Defender Crisis: - Manual defender processes versus scaled adversary automation - Quarterly asset inventories face adversaries with continuous discovery - Unknown assets become critical vulnerabilities - Speed of response becomes existential

Implementation Impact: Manual security processes become existential vulnerabilities

The Capability Gap

Organizations relying on quarterly asset inventories face adversaries who discover vulnerabilities continuously at internet scale. No amount of hiring closes this gap—only automation can match automated adversaries.

Assessment Questions¶

Use these questions to determine your attack landscape maturity:

Question	Low Maturity	Moderate Maturity	High Maturity
Discovery Speed	We discover assets before attackers	Roughly equal	Attackers discover before us
Attack Automation	Targeted manual attacks	Some automated scans	Industrial-scale automation
Exploitation Speed	Days to weeks	Hours to days	Minutes to hours after disclosure
Reconnaissance Scale	Targeted orgs	Industry sectors	Internet-wide sweeps
Unknown Asset Risk	Low concern	Moderate concern	Critical vulnerability

Impact on Strategy¶

For All Quadrants¶

High attack landscape maturity accelerates the need for automation regardless of your strategic position:

Visionaries: Implement continuous monitoring and automated security from inception—can't rely on manual processes even at small scale

Leaders: Advanced threat detection and response automation become critical—scale advantages only work with automation

Niche Players: Must prioritize basic automation earlier than typical roadmap—manual processes create existential risk

Challengers: Automation becomes urgent even with limited operational readiness—hybrid manual/automated approaches insufficient

Investment Priorities¶

Low Maturity Context: - Manual security processes remain viable - Gradual automation roadmap acceptable - Focus on process maturity before automation

Moderate Maturity Context: - Begin prioritizing automation investments - Accelerate continuous monitoring capabilities - Balance manual and automated approaches

High Maturity Context: - Automation becomes existential priority - Supply chain continuous monitoring critical - Asset discovery automation required - Real-time vulnerability detection essential - Rapid response automation necessary

Real-World Indicators¶

You're facing high attack landscape maturity when:

✅ Attackers are exploiting vulnerabilities within hours of disclosure
✅ You're discovering unauthorized systems during incident response
✅ External parties notify you of assets you didn't know existed
✅ Automated scanning attempts occur continuously
✅ Credential stuffing attacks happen at scale
✅ Supply chain attacks target your dependencies systematically

Strategic Response¶

Short-Term (0-6 months)¶

Asset Discovery Automation: Implement continuous asset inventory
Vulnerability Scanning: Move from quarterly to continuous scanning
Threat Intelligence: Subscribe to real-time threat feeds
Incident Detection: Deploy automated monitoring for critical systems

Medium-Term (6-18 months)¶

Security Orchestration: Automate response to common attacks
Supply Chain Monitoring: Continuous dependency vulnerability tracking
Attack Surface Management: Automated external attack surface discovery
Threat Hunting: Proactive automated threat detection

Long-Term (18+ months)¶

AI-Powered Detection: Machine learning for anomaly detection
Autonomous Response: Self-healing systems for common attacks
Predictive Security: Anticipate attacks before they occur
Security-as-Code: Complete automation of security controls

Connection to Supply Chain Stewardship¶

High attack landscape maturity makes Supply Chain Stewardship the #1 priority because:

Adversaries discover supply chain vulnerabilities at scale
Dependency confusion attacks happen automatically
Compromised packages detected through industrial scanning
Manual dependency tracking can't keep pace

This is why supply chain became the #1 priority when the attack landscape matured to industrial-scale automation.

Next Steps¶

Continue to Supply Chain Complexity Back to Contextual Modifiers Overview

Supply Chain Complexity¶

Beyond Volume: Complexity as Risk Multiplier¶

Supply chain complexity isn't just about the number of dependencies—it's about the interconnected risk created by multi-tier dependencies, critical single vendors, and geopolitical constraints.

May Require Leaders-Level Tools

High supply chain complexity may require Leaders-level supply chain tools regardless of your base quadrant position. Organizations with critical supply chains should prioritize supply chain stewardship investments early.

Complexity Levels¶

Simple Supply Chain¶

Characteristics: - Standard dependencies with known vendors - Direct relationships (minimal tiers) - Straightforward compliance - Geographic simplicity - Minimal single points of failure

Implementation: Standard supply chain stewardship from your quadrant

Complex Supply Chain¶

Characteristics: - Multi-tier dependencies (2-3 levels deep) - Critical SaaS integrations - Multiple geographic regions - Some vendor concentration risk - Industry-standard security requirements

Implementation: Enhanced supply chain visibility and management

Critical Supply Chain¶

Characteristics: - National security implications - Highly regulated vendors (defense, finance) - Geopolitical constraints and restrictions - Critical single vendors (business-critical dependencies) - Supply chain attacks as existential risk

Implementation: Enterprise-grade supply chain security regardless of operational complexity

Assessment Questions¶

Question	Simple	Complex	Critical
Dependency tiers?	1-2 levels	2-3 levels	3+ levels with unknowns
Single vendor risk?	Multiple alternatives	Some concentration	Critical dependencies
Geopolitical concerns?	Minimal	Moderate	Significant constraints
Regulatory requirements?	Standard	Industry-specific	Government/defense
Supply chain attack impact?	Recoverable	Significant	Existential

Impact on Strategic Position¶

Simple Supply Chain¶

Follow standard quadrant approach for supply chain stewardship

Complex Supply Chain¶

Enhanced SBOM capabilities required
Multi-tier dependency tracking
Vendor relationship management program
Supply chain risk scoring

Critical Supply Chain¶

Requires Leaders-level capabilities even in other quadrants:

Niche Players with Critical Supply Chain: - Implement enterprise SBOM tools early - Comprehensive vendor security program - May need dedicated supply chain security role

Challengers with Critical Supply Chain: - Prioritize supply chain modernization - Hybrid approaches with enhanced visibility - Balance legacy and modern supply chain security

Visionaries with Critical Supply Chain: - Leverage advanced supply chain automation - Policy-as-code for supply chain governance - AI-powered supply chain risk analysis

Next Steps¶

Continue to Regulatory Constraints Back to Attack Landscape

Regulatory Constraints¶

Compliance Overhead as Strategic Constraint¶

Regulatory requirements directly affect your security implementation approach by increasing BAU workload, constraining technology choices, and potentially delaying transformation initiatives.

Constraint Levels¶

Minimal Regulatory¶

Standard business compliance (GDPR, basic privacy) - Flexible implementation choices - Standard commercial tools acceptable - Regular but manageable audit cycles

Implementation Impact: Minimal constraint on security strategy

Sector-Specific¶

Industry requirements (HIPAA, PCI-DSS, SOX) - Constrained technology choices - Regular audit cycles with documentation burden - Industry-specific security controls - Compliance-driven BAU workload

Implementation Impact: Increases BAU burden; factor into capacity planning

High-Stakes Regulatory¶

Government/defense (FedRAMP, financial regulations) - Severely limited technology options - Continuous compliance monitoring - Extensive documentation requirements - Compliance as gating factor for changes

Implementation Impact: May extend transformation timelines; compliance becomes primary constraint

Assessment Questions¶

Question	Minimal	Sector-Specific	High-Stakes
Audit frequency?	Annual	Quarterly	Continuous
Technology constraints?	Minimal	Moderate	Severe
Documentation burden?	Standard	Significant	Extensive
Compliance violation risk?	Manageable	Serious	Existential

Strategic Implications¶

Factor compliance overhead into: Capacity planning, Timeline estimates, Tool selection, Change management

Opportunities during compliance: Crisis events, Audit findings, Regulatory changes

Next Steps¶

Continue to Crisis Events Back to Supply Chain Complexity

Crisis Events¶

Strategic Opportunity Through Disruption¶

Crisis events create unique windows for organizational change. Security incidents, compliance failures, and business disruptions can rapidly accelerate quadrant movement by shifting organizational priorities and unlocking resources.

Crisis as Catalyst

Well-managed crisis events can compress years of gradual transformation into months of focused change. The key is being prepared with strategic plans when crisis creates opportunity.

Types of Crisis Events¶

Security Incidents¶

Data breaches
Ransomware attacks
Supply chain compromises
System compromises
Customer data exposure

Compliance Failures¶

Audit failures
Regulatory violations
Certification losses
Customer security requirement failures

Business Disruptions¶

Service outages from security issues
Customer impact from security gaps
Revenue loss from security incidents
Market reputation damage

Impact on Transformation¶

Pre-Crisis¶

Normal state: Gradual change, competing priorities, incremental budgets

Security position: Requested but not urgent

During Crisis¶

Heightened urgency: Security becomes top priority, resources unlock, decisions accelerate

Window of opportunity: 3-6 months of elevated priority and funding

Post-Crisis¶

Two possible outcomes:

Sustained Change: Crisis leads to lasting organizational transformation and continued investment
Return to Normal: Initial momentum fades, priorities revert, limited lasting impact

Strategic Response to Crisis¶

Immediate Response (Days)¶

Contain and resolve crisis
Communicate transparently
Document lessons learned
Begin root cause analysis

Short-Term Exploitation (Weeks-Months)¶

Present strategic security roadmap
Secure funding for scaling investments
Fast-track approved initiatives
Build momentum for transformation

Long-Term Transformation (Months-Years)¶

Implement sustained security improvements
Build on crisis-driven approvals
Maintain executive attention
Demonstrate measurable progress

Assessment Questions¶

Question	Minor	Moderate	Major
Recent incidents?	Operational issues	Security incidents	Major breaches
Business impact?	Minimal	Significant	Existential
Organizational changes?	None	Some adjustments	Fundamental transformation
Lasting effects?	Temporary	Moderate duration	Permanent changes

Using Crisis Strategically¶

Be Prepared: - Maintain ready strategic roadmap - Have business cases prepared - Know required resources - Understand organizational blockers

Act Quickly: - Present solutions during crisis - Secure commitments while urgent - Fast-track initiatives - Build irreversible momentum

Sustain Changes: - Deliver quick wins - Demonstrate measurable improvement - Maintain executive visibility - Build lasting capabilities

Common Pitfalls¶

Crisis Anti-Patterns

Reactive-Only: Fixing immediate issue without strategic improvements

Over-Promising: Commitments that can't be sustained post-crisis

Wasted Window: Missing opportunity while crisis urgency exists

Return to Normal: Allowing organizational attention to fade

Next Steps¶

Continue to Change Capacity Back to Regulatory Constraints

Change Capacity¶

Organizational Ability to Absorb Transformation¶

Change capacity determines how quickly you can implement security transformations. It affects transition speed, scaling investment success probability, and overall transformation timeline.

Capacity Levels¶

Risk-Averse / Slow Adoption¶

Conservative culture
Lengthy approval processes
Resistance to new tools
Gradual rollout requirements
Change fatigue from previous initiatives

Implementation Impact: Extend timelines, increase change management investment, pilot-first approaches

Selective / Gradual Rollouts¶

Measured approach to change
Pilot programs before broad adoption
Structured change management
Balanced innovation and stability

Implementation Impact: Standard transformation timelines with appropriate checkpoints

Innovation Culture / Rapid Experimentation¶

Embrace of change
Fast decision-making
Tolerance for experimentation
Quick adoption of new tools
Learning-oriented culture

Implementation Impact: Accelerate transformation timelines, reduce change management overhead

Assessment Questions¶

Question	Low Capacity	Moderate Capacity	High Capacity
Tool rollout timeline?	12+ months	6-12 months	3-6 months
Process disruption tolerance?	Very low	Moderate	High
Change management resources?	Limited	Adequate	Strong
Recent change success?	Mixed/negative	Generally positive	Consistently successful
Cultural innovation orientation?	Risk-averse	Balanced	Innovation-focused

Strategic Implications¶

Low change capacity requires: - Longer transformation timelines - More extensive pilots and proofs-of-concept - Significant change management investment - Incremental rather than transformative changes - Strong executive sponsorship

High change capacity enables: - Compressed transformation timelines - Bold strategic investments - Rapid experimentation and iteration - Transformative rather than incremental changes

Next Steps¶

Continue to Relationship Health Back to Crisis Events

Relationship Health¶

Trust as Implementation Accelerator¶

The health of relationships between security and engineering teams directly affects adoption velocity and scaling investment success. Strong relationships enable rapid transformation; damaged relationships create friction and delay.

Relationship Levels¶

Damaged Relationships¶

Security seen as blocker
Minimal communication
Adversarial interactions
Security bypassed when possible
Mutual distrust

Implementation Impact: Significant adoption challenges; must rebuild trust before transformation

Functional but Transactional¶

Working relationship exists
Reactive consultations
Compliance-focused interactions
Limited collaboration
Professional but not strategic

Implementation Impact: Standard adoption patterns; some friction expected

Strategic Partnership¶

Security as enabler
Proactive collaboration
Shared objectives
Voluntary participation
Mutual trust and respect

Implementation Impact: Accelerated adoption; reduced friction; innovation opportunities

Assessment Questions¶

Question	Damaged	Functional	Strategic
Proactive consultation frequency?	Rare	Occasional	Regular
Voluntary participation in security initiatives?	Low	Moderate	High
Security seen as?	Blocker	Necessary function	Partner/enabler
Collaborative incident response?	Blamed	Coordinated	Blameless
Developer satisfaction with security?	Low	Neutral	Positive

Building Strong Relationships¶

For Damaged Relationships: 1. Listen and acknowledge past friction 2. Focus on quick wins that reduce developer pain 3. Be transparent about constraints 4. Deliver on commitments consistently 5. Measure and improve developer experience

For Functional Relationships: 1. Increase proactive engagement 2. Collaborate on shared objectives 3. Invest in developer-friendly security tools 4. Celebrate joint successes 5. Build security champions program

For Strategic Partnerships: 1. Maintain momentum through continuous improvement 2. Co-design security capabilities 3. Share ownership of security outcomes 4. Innovate together on security solutions 5. Expand collaboration across organization

Impact on Transformation¶

Strong relationships enable: - Faster adoption of scaling investments - Higher voluntary participation rates - Better feedback and iteration - Innovation opportunities - Sustainable transformation

Weak relationships require: - Extended relationship-building before transformation - More mandatory controls (less voluntary adoption) - Slower rollouts with more resistance - Limited innovation opportunities - Higher risk of transformation failure

Next Steps¶

You've completed all six contextual modifiers! Return to the overview or continue to Implementation Guides:

Continue to Implementation Guides Back to Contextual Modifiers Overview

Implementation Guides

Implementation Guide: Visionaries¶

Position Characteristics¶

Visionaries occupy the Simple + High Readiness quadrant:

Small to medium operational complexity (10-200 engineers)
Modern infrastructure (cloud-native, infrastructure-as-code)
Strong automation foundation (CI/CD, automated testing)
Fast decision-making (minimal bureaucracy)
Innovation culture (experimentation encouraged)

Strategic Priorities¶

1. Maintain Velocity While Building Security¶

Your advantage is speed. Security should accelerate, not slow down.

Investment Focus: - Automated security scanning integrated into CI/CD - Secure templates and paved roads for common patterns - Self-service security capabilities for developers - Policy-as-code from the start

Avoid: - Manual security review bottlenecks - Process for process's sake - Premature complexity (don't build Leaders-level tools yet)

2. Embed Security in Modern Infrastructure¶

You're building on cloud-native foundations. Embed security from inception.

Investment Focus: - Infrastructure security automation (cloud posture management) - Container and Kubernetes security guardrails - Automated compliance validation - Supply chain security from day one (SBOM, dependency scanning)

Avoid: - Bolting security on after architecture decisions - Manual cloud configuration review - Treating security as separate from infrastructure

3. Build Foundations for Scale¶

You're positioned to scale efficiently. Build the right foundations now.

Investment Focus: - Security platforms over point solutions - Reusable security capabilities (not one-off solutions) - Documentation and self-service patterns - Metrics that matter (outcomes, not activity)

Avoid: - Tool sprawl without integration - Heroic manual efforts that can't scale - Missing the inflection point before scaling crisis

Quick Start Checklist¶

Week 1: Assessment¶

[ ] Map current operational complexity and readiness level
[ ] Identify manual security bottlenecks
[ ] Assess relationship health with engineering teams
[ ] Review current security tool coverage

Month 1: Foundation¶

[ ] Deploy automated security scanning (SAST, dependency scanning, container scanning)
[ ] Create secure templates for 3 most common patterns
[ ] Establish security documentation hub
[ ] Define security review triage criteria (what needs manual review vs. automated)

Quarter 1: Automation¶

[ ] Implement CI/CD security gate automation
[ ] Create self-service security documentation
[ ] Deploy policy-as-code for infrastructure
[ ] Establish security metrics dashboard

Quarter 2: Scaling¶

[ ] Reduce manual security reviews by 70% through automation
[ ] Launch security champions pilot program
[ ] Implement runtime security monitoring
[ ] Build feedback loops for continuous improvement

Investment Roadmap¶

Year 1: Build Scaling Foundations¶

BAU to Constrain (30% effort): - Manual security reviews for novel architectures only - Critical incident response - Compliance validation (automate where possible)

Scaling Investments (70% effort): - Automated security scanning platform - Secure templates and paved roads - Self-service capabilities - Policy-as-code infrastructure

Expected Outcomes: - 70% reduction in manual security review time - 3x increase in deployment frequency without security incidents - Security embedded in default paths

Year 2: Optimize and Extend¶

BAU to Constrain (20% effort): - Maintain only truly unique security reviews - Automated incident response where possible

Scaling Investments (80% effort): - Advanced security automation (threat modeling as code) - Supply chain security platform - Runtime security with automated response - Security product capabilities (if customer-facing software factory)

Expected Outcomes: - Sub-hour security review for 90% of changes - Proactive vulnerability detection before exploitation - Security as competitive advantage

Common Pitfalls¶

Premature Complexity¶

Risk: Building Leaders-level tooling before you need it

Symptoms: - Creating complex security platforms for simple needs - Over-engineering automation - Analysis paralysis on tool selection

Solution: Start simple, add complexity as operations scale

Missing the Scaling Crisis¶

Risk: Not recognizing when manual processes are failing

Symptoms: - Security reviews taking weeks instead of hours - Security team overwhelmed with ticket backlog - Engineering teams bypassing security to meet deadlines

Solution: Proactively constrain BAU before crisis hits

Process Over Outcomes¶

Risk: Importing heavyweight processes that slow innovation

Symptoms: - Security reviews requiring extensive documentation for simple changes - Multiple approval layers for standard patterns - Compliance theater instead of actual risk reduction

Solution: Focus on secure defaults and automation, not manual gates

Success Indicators¶

6 Months¶

[ ] Manual security review time reduced 50% (from baseline)
[ ] Automated scanning detecting 80%+ of security issues before human review
[ ] Secure templates used for 60%+ of new services
[ ] Developer satisfaction with security improved (measured via survey)

12 Months¶

[ ] Manual security review time reduced 70% (from baseline)
[ ] Security review SLA: 90% completed within 2 hours for standard patterns
[ ] Zero critical security incidents from standard patterns
[ ] Security champions program launched with 5+ active participants

24 Months¶

[ ] Manual security review time reduced 80% (from baseline)
[ ] Security embedded in default engineering workflows (no separate security step)
[ ] Proactive vulnerability detection before external disclosure
[ ] Security as competitive advantage (measurable customer trust improvement)

Movement Paths¶

Maintaining Position: Staying Visionary¶

As your organization grows, operational complexity will naturally increase. To maintain the Visionary position:

Strategy: Continuously optimize processes and automation as you scale

Key Investments: - Automation that scales with team growth - Self-service capabilities to maintain velocity - Strong onboarding for security patterns - Avoid complexity creep

Timeline: Ongoing; requires continuous attention

Advancing to Leaders¶

When operational complexity increases (100+ engineers, multiple products):

Strategy: Thoughtful complexity management while maintaining readiness

Key Investments: - Platform security capabilities - Advanced automation for complex scenarios - Policy-as-code at organizational scale - Security product capabilities

Timeline: 18-36 months as complexity naturally increases

Critical Success Factor: Don't let increased complexity degrade operational readiness

Next Steps¶

Continue to Leaders Implementation Back to Contextual Modifiers

Edit this page

Implementation Guide: Leaders¶

Position Characteristics¶

Leaders occupy the Complex + High Readiness quadrant:

Large-scale operational complexity (200+ engineers, multiple products/services)
Mature infrastructure (sophisticated cloud platforms, advanced automation)
Strong security foundations (established security programs, proven capabilities)
Platform-oriented (internal platforms serving multiple teams)
Optimization focus (refining what works, eliminating waste)

Strategic Priorities¶

1. Optimize What Works, Eliminate What Doesn't¶

You have established security capabilities. Focus on optimization and continuous improvement.

Investment Focus: - Data-driven optimization of existing security platforms - Eliminate security theater (activities that don't reduce risk) - Advanced automation to replace remaining manual processes - Security engineering productivity tools

Avoid: - Complacency (maintaining status quo) - Adding capabilities without retiring old ones (tool sprawl) - Activity metrics over outcome metrics

2. Scale Security Through Platform Effects¶

Your complexity requires platform thinking. Build capabilities that serve multiple teams.

Investment Focus: - Security platforms with self-service capabilities - Policy-as-code at organizational scale - Federated security models (security champions, guild structure) - Reusable security components and libraries

Avoid: - Centralized bottlenecks (security as single point of failure) - One-size-fits-all solutions (enable teams to customize within guardrails) - Platform features without adoption focus

3. Innovate for Competitive Advantage¶

Security should be a differentiator, not just cost center.

Investment Focus: - Security product capabilities (if customer-facing software factory) - Advanced threat detection and response - Supply chain security leadership - Security research and thought leadership

Avoid: - Innovation for innovation's sake - Pursuing cutting-edge at expense of fundamentals - Building capabilities that don't align with business strategy

Quick Start Checklist¶

Month 1: Assessment¶

[ ] Conduct comprehensive capability assessment across all stewardship areas
[ ] Identify high-effort, low-impact security activities (candidates for elimination)
[ ] Map platform adoption rates and satisfaction
[ ] Review outcome metrics (not just activity metrics)

Quarter 1: Optimization¶

[ ] Eliminate or automate 3 low-value security activities
[ ] Implement data-driven optimization for top security platform
[ ] Establish federated security model (champions, guilds)
[ ] Define clear outcome metrics for each stewardship area

Quarter 2: Innovation¶

[ ] Launch advanced automation pilot (threat modeling as code, automated remediation)
[ ] Implement cross-team security capability sharing
[ ] Deploy advanced supply chain security capabilities
[ ] Establish security research program

Quarter 3-4: Scale¶

[ ] Expand successful pilots across organization
[ ] Build security product capabilities (if applicable)
[ ] Establish industry thought leadership presence
[ ] Continuously optimize based on metrics

Investment Roadmap¶

Year 1: Optimize and Scale¶

BAU to Constrain (10-15% effort): - Truly unique security challenges requiring expert review - Strategic incident response (automated where possible) - Critical compliance audits (automate evidence collection)

Scaling Investments (85-90% effort): - Platform optimization and adoption improvement - Advanced automation (threat modeling, automated remediation) - Federated security models - Security product capabilities - Tool consolidation and retirement

Expected Outcomes: - 50% reduction in manual security work through optimization - 90%+ of teams using security platforms voluntarily - Security capabilities as competitive advantage - Industry recognition for security leadership

Year 2: Lead the Industry¶

BAU to Constrain (5-10% effort): - Only truly novel security challenges - Strategic advisory for critical decisions

Scaling Investments (90-95% effort): - Advanced security research and innovation - Open source security leadership - Industry standard contribution - Security product innovation - AI-powered security capabilities

Expected Outcomes: - Security as measurable competitive advantage - Industry thought leadership - Attracting top security talent through reputation - Security capabilities ahead of adversary evolution

Common Pitfalls¶

Complacency¶

Risk: Resting on past success while adversaries evolve

Symptoms: - "We've always done it this way" mentality - Declining participation in security programs - Missing emerging threats (supply chain, AI security) - Slow response to industry changes

Solution: Continuous innovation and experimentation culture

Tool Sprawl Without Retirement¶

Risk: Accumulating security tools without sunsetting old ones

Symptoms: - 20+ security tools with overlapping capabilities - Low adoption rates across multiple tools - Alert fatigue from redundant tooling - High operational overhead maintaining tools

Solution: Regular capability assessment with intentional retirement

Optimization Over Innovation¶

Risk: Focusing on incremental improvements while missing strategic shifts

Symptoms: - All security investments are optimizations of existing capabilities - No exploration of emerging security paradigms - Falling behind on supply chain, AI, cloud-native security - Inability to attract innovative security talent

Solution: Balance 70% optimization with 30% innovation

Platform Without Adoption¶

Risk: Building sophisticated platforms nobody uses

Symptoms: - Low voluntary adoption of security platforms - Teams building workarounds instead of using platforms - Platform teams focused on features, not user experience - Disconnect between platform capabilities and team needs

Solution: Product management approach to security platforms with adoption metrics

Success Indicators¶

6 Months¶

[ ] Manual security effort reduced 30% through optimization
[ ] Security platform adoption >80% for primary platforms
[ ] 3+ low-value activities eliminated or fully automated
[ ] Outcome metrics defined and baseline established for all stewardship areas

12 Months¶

[ ] Manual security effort reduced 50% (from baseline)
[ ] Security platform voluntary adoption >90%
[ ] Advanced automation deployed (threat modeling as code, automated remediation)
[ ] Measurable security competitive advantage (customer trust metrics, compliance differentiators)

24 Months¶

[ ] Security almost entirely self-service (sub-5% manual effort)
[ ] Industry thought leadership established (conference talks, research publications)
[ ] Security product capabilities providing customer value
[ ] Attracting top security talent through reputation and innovation

Movement Paths¶

Maintaining Position: Staying Leader¶

Continuous effort required to maintain leadership position:

Strategy: Continuous innovation and optimization to stay ahead

Key Investments: - Ongoing platform optimization - Cutting-edge security research - Industry collaboration and standards contribution - Attract and retain top security talent

Timeline: Ongoing; leadership requires constant investment

Critical Success Factor: Balance innovation with operational excellence

Risk: Regressing to Challenger¶

Without continuous investment, complexity can overwhelm readiness:

Warning Signs: - Manual processes creeping back in - Platform adoption declining - Security becoming bottleneck again - Team morale declining

Prevention: - Maintain 85%+ effort on scaling investments - Ruthlessly eliminate low-value activities - Continuous improvement culture - Regular capability reassessment

Advanced Capabilities¶

Threat Modeling as Code¶

Automated threat modeling integrated into development workflow: - Infrastructure-as-code scanning for security patterns - Automated risk assessment based on component composition - Self-service threat model generation

Automated Remediation¶

Moving beyond detection to automated response: - Auto-patching for approved vulnerability classes - Automated security configuration drift correction - Self-healing security controls

Security Product Capabilities¶

If you operate a customer-facing software factory: - Security features as product differentiators - Compliance certifications as competitive advantage - Security transparency as trust builder

Supply Chain Security Leadership¶

Advanced supply chain security: - Complete SBOM across all products - Continuous supply chain monitoring - Vendor security posture management - Proactive vulnerability intelligence

Next Steps¶

Continue to Niche Players Implementation Back to Visionaries Implementation

Edit this page

Implementation Guide: Niche Players¶

Position Characteristics¶

Niche Players occupy the Simple + Low Readiness quadrant:

Simple operational complexity (typically <50 engineers, single product/service)
Legacy or basic infrastructure (manual processes, limited automation)
Resource constraints (small teams, limited budget)
Pragmatic focus (solving immediate problems, not building for scale)
Critical decision point (modernize strategically or stay intentionally simple)

Strategic Priorities¶

1. Determine Your Strategic Path¶

The most important decision: intentional simplicity or prepare for growth?

Option A: Intentional Simplicity (Remain Niche Player) - Small team, focused product, sustainable operations - Security through simplicity (small attack surface) - Selective modernization only where it reduces operational burden - Appropriate for: Lifestyle businesses, internal tools, specialized services

Option B: Prepare for Growth (Move toward Visionary) - Anticipate operational growth - Invest in infrastructure modernization now - Build foundations that will scale - Appropriate for: Funded startups, expanding services, growth trajectory

Critical: Choose intentionally. Don't accidentally drift into wrong model.

2. Security Through Simplicity¶

Your advantage is small scale. Leverage it.

Investment Focus: - Managed security services (SaaS over self-hosted) - Secure defaults over complex configuration - Cloud provider security features (don't build your own) - Essential security only (supply chain, patching, basic monitoring)

Avoid: - Building complex security infrastructure - Manual processes that don't scale (if growth expected) - Premature optimization - Enterprise security frameworks designed for complexity

3. Strategic Modernization Choices¶

If preparing for growth, modernize strategically to build Visionary foundations.

Investment Focus: - Cloud migration (if still on-premises) - CI/CD basics (automated deployment) - Infrastructure-as-code foundations - Automated security scanning (managed services)

Avoid: - "Lift and shift" cloud migration (recreating legacy in cloud) - Over-engineering for hypothetical scale - Modernization without clear business value - Modernization debt (half-finished migrations)

Quick Start Checklist¶

Week 1: Strategic Decision¶

[ ] Determine strategic path: Intentional simplicity or prepare for growth?
[ ] Assess current security posture against critical risks
[ ] Identify biggest security pain points
[ ] Define realistic security goals given resources

Month 1: Essential Security¶

[ ] Implement automated dependency scanning (managed service)
[ ] Establish basic vulnerability patching process
[ ] Deploy managed security monitoring (cloud provider features)
[ ] Document critical systems and dependencies

Quarter 1: Foundation (If Preparing for Growth)¶

[ ] Begin cloud migration planning (if on-premises)
[ ] Implement basic CI/CD pipeline
[ ] Establish infrastructure-as-code for new systems
[ ] Deploy automated security scanning in CI/CD

Quarter 2: Modernization (If Preparing for Growth)¶

[ ] Complete cloud migration for priority systems
[ ] Expand automation to cover deployment process
[ ] Implement security guardrails in infrastructure
[ ] Begin tracking operational readiness metrics

Investment Roadmap¶

Path A: Intentional Simplicity (Remain Niche Player)¶

Year 1 Focus: - Maintain essential security through managed services (80% effort) - Selective modernization only where it reduces burden (20% effort)

Security Approach: - Managed security services (SaaS tools, cloud provider features) - Supply chain security (dependency scanning, SBOM) - Basic vulnerability management (automated patching) - Essential monitoring (security logs, basic alerting)

Expected Outcomes: - Appropriate security without operational burden - Low total cost of ownership - Sustainable operations at current scale

Path B: Prepare for Growth (Move toward Visionary)¶

Year 1: Infrastructure Modernization (70% effort on modernization) - Cloud migration (if on-premises) - CI/CD automation - Infrastructure-as-code - Automated security in pipeline

Year 2: Security Automation (50% modernization, 50% security automation) - Expanded security scanning - Security guardrails in infrastructure - Self-service secure templates - Monitoring and response capabilities

Expected Outcomes: - Visionary quadrant positioning after 18-24 months - Security embedded in modern infrastructure - Ready to scale with business growth - Avoided technical debt from premature scaling

Common Pitfalls¶

Accidental Path Drift¶

Risk: Unintentionally growing complexity without increasing readiness

Symptoms: - Adding features without modernizing infrastructure - Team growing but still manual processes - Increasing operational burden without automation - "Technical debt" accumulating

Solution: Make intentional strategic choice and revisit quarterly

Premature Optimization¶

Risk: Building for scale you may never reach

Symptoms: - Complex security infrastructure for 10-person team - Self-hosting tools that could be SaaS - Extensive automation for rare scenarios - More time on security infrastructure than product

Solution: Security should be appropriate to scale and risk

Wrong Modernization Sequence¶

Risk: Modernizing in wrong order creates more problems

Symptoms: - Lift-and-shift cloud migration (legacy architecture in cloud) - Adding automation to broken processes - Infrastructure-as-code for unstable architecture - Security tools before foundational security

Solution: Modernize infrastructure foundations first, then add security

Resource Exhaustion¶

Risk: Attempting Visionary/Leaders approaches with Niche Player resources

Symptoms: - Security team overwhelmed trying to build platforms - Half-finished modernization projects - Burnout from unsustainable manual work - Critical systems neglected for aspirational projects

Solution: Right-size security investments to actual resources

Success Indicators¶

Path A: Intentional Simplicity¶

6 Months: - [ ] Essential security implemented (dependency scanning, patching, basic monitoring) - [ ] Managed services handling 80%+ of security (minimal operational burden) - [ ] Security incidents responded to within 24 hours - [ ] Sustainable security operations (not requiring heroic effort)

12 Months: - [ ] Zero critical vulnerabilities in production (through automated scanning and patching) - [ ] Security integrated into development workflow (not separate process) - [ ] Quarterly security reviews (confirming approach still appropriate) - [ ] Team satisfaction with security approach (not excessive burden)

Path B: Prepare for Growth¶

6 Months: - [ ] Cloud migration plan finalized (if applicable) or basic CI/CD operational - [ ] Automated security scanning deployed - [ ] Infrastructure-as-code for 30%+ of systems - [ ] Operational readiness metrics tracked

12 Months: - [ ] Cloud migration 80% complete (if applicable) - [ ] CI/CD automation covering all deployments - [ ] Infrastructure-as-code for 70%+ of systems - [ ] Security embedded in deployment pipeline

18-24 Months: - [ ] Visionary quadrant positioning achieved - [ ] Security automation at Visionary level (see Visionaries guide) - [ ] Ready to scale with business growth - [ ] Technical debt minimal

Movement Paths¶

Staying Intentionally Simple (Maintain Niche Player)¶

This is a valid, sustainable choice for many organizations:

When Appropriate: - Stable team size (<20 people) - Single focused product/service - Not venture-funded or seeking rapid growth - Strong product-market fit at current scale

Strategy: - Leverage managed services for security - Security through simplicity (small attack surface) - Quarterly reassessment of strategic choice - Prepared to pivot if growth trajectory changes

Timeline: Ongoing; sustainable at this scale

Moving to Visionary (Simple + High Readiness)¶

Preparing infrastructure for growth:

Strategy: Single-axis movement (increase operational readiness)

Key Investments: - Cloud infrastructure (if not already cloud-native) - CI/CD automation - Infrastructure-as-code - Automated security scanning

Timeline: 18-24 months for complete transformation

Success Probability: High (single-axis movement is achievable)

Critical Success Factors: - Clear business case for modernization - Adequate resources (time, money, expertise) - Avoid half-finished modernization - Security embedded during modernization (not bolted on after)

Risk: Accidental Drift to Challenger¶

Growing complexity without increasing readiness:

Warning Signs: - Team growing but processes still manual - Multiple products but no platform thinking - Increasing operational burden without automation - Security becoming bottleneck

Prevention: - Intentional strategic choice reviewed quarterly - If growing complexity, invest in operational readiness - If not investing in readiness, constrain complexity - Never accidentally drift between quadrants

Decision Framework¶

Use this to determine your strategic path:

Question	Intentional Simplicity	Prepare for Growth
Expected team growth?	Stable (<20)	Growing (20-200+)
Funding model?	Sustainable revenue	Venture-funded
Product strategy?	Single focused product	Platform/multiple products
Market position?	Niche/specialized	Expansion/growth
Risk tolerance?	Conservative	Growth-oriented
Infrastructure age?	Legacy OK if working	Must modernize

Next Steps¶

Continue to Challengers Implementation Back to Leaders Implementation

Edit this page

Implementation Guide: Challengers¶

Position Characteristics¶

Challengers occupy the Complex + Low Readiness quadrant:

High operational complexity (100+ engineers, multiple products/services)
Legacy infrastructure (manual processes, limited automation, technical debt)
Resource constraints (security team stretched thin, competing priorities)
Transformation imperative (current state unsustainable at scale)
Highest transformation risk (two-axis movement required)

The Challenger Reality¶

This is the most difficult transformation journey. You must simultaneously: - Reduce operational burden (can't maintain current manual load) - Increase automation (while systems resist automation) - Maintain operations (can't stop to renovate) - Navigate organizational resistance (change is hard)

Critical Truth: Two-axis movement (complexity + readiness) has high failure risk. Success requires strategic sequencing, executive support, and realistic timelines.

Strategic Priorities¶

1. Stabilize Before Transforming¶

Don't attempt transformation while drowning in operational work.

First Priority: Achieve operational stability - Constrain BAU growth (say no to low-value work) - Automate or eliminate highest-burden activities - Build breathing room for strategic work - Secure executive support for transformation

Investment Focus: - Quick automation wins (eliminate repetitive manual work) - Tool consolidation (reduce operational overhead) - Relationship building with engineering (you'll need their help) - Documentation of current state (know what you're transforming from)

Timeline: 6-12 months before major transformation begins

2. Choose Your Transformation Path¶

Two possible strategies, each with different tradeoffs:

Path A: Reduce Complexity First (Move toward Niche Players) - Strategy: Simplify operations while modernizing what remains - Examples: Consolidate products, retire legacy systems, reduce scope - Advantages: Easier transformation, clearer focus, faster progress - Challenges: May require difficult business decisions, potential revenue impact - Timeline: 12-24 months to Niche Players, then 18-24 to Visionaries

Path B: Increase Readiness Despite Complexity (Move toward Leaders) - Strategy: Gradual modernization while maintaining complex operations - Examples: Hybrid approaches, phased rollouts, incremental automation - Advantages: Maintains business operations, no scope reduction needed - Challenges: Longest timeline, highest failure risk, requires sustained investment - Timeline: 36-60 months to Leaders (realistically)

Critical Decision Factors: - Executive support and patience (Path B requires 3-5 year commitment) - Resource availability (Path B needs significant sustained investment) - Business model (Can you reduce complexity without hurting revenue?) - Organizational change capacity (Path B requires high tolerance for disruption)

3. Execute Hybrid Transformation¶

Regardless of path, you'll need hybrid approaches:

Modern + Legacy Coexistence: - Modern security for new systems (cloud-native, automated) - Pragmatic controls for legacy systems (appropriate to modernization timeline) - Gradual migration (not big-bang transformation) - Clear criteria for what gets modernized when

Investment Focus: - Security automation for new systems (don't recreate manual processes) - Managed services for legacy (reduce operational burden) - Platform capabilities that serve both (unified monitoring, identity) - Clear boundaries between modern and legacy

Quick Start Checklist¶

Month 1-3: Stabilization¶

[ ] Document current state: operational burden, manual processes, pain points
[ ] Identify 3 highest-burden manual activities for elimination/automation
[ ] Assess relationship health with engineering teams
[ ] Secure executive sponsor for transformation (critical for success)
[ ] Map which systems are candidates for modernization vs. retirement

Month 4-6: Quick Wins¶

[ ] Eliminate or automate at least 1 high-burden manual activity
[ ] Implement managed security service for at least 1 capability
[ ] Launch relationship-building initiative with engineering
[ ] Define transformation path (reduce complexity or increase readiness)
[ ] Create high-level transformation roadmap with executive sponsor

Month 7-12: Foundation¶

[ ] Establish modern security for new systems (break legacy pattern)
[ ] Deploy automated security scanning for active development
[ ] Begin infrastructure modernization pilot
[ ] Measure and track operational burden reduction
[ ] Communicate transformation progress to stakeholders

Year 2: Transformation Launch¶

[ ] Execute on chosen path (complexity reduction or readiness increase)
[ ] Establish success metrics and track progress
[ ] Regular executive updates on transformation progress
[ ] Course-correct based on what's working/not working

Investment Roadmap¶

Path A: Reduce Complexity First (→ Niche Players → Visionaries)¶

Year 1: Stabilize + Plan Complexity Reduction - Stabilization (50% effort): Quick automation wins, operational burden reduction - Complexity Assessment (30% effort): What can be simplified, consolidated, retired? - Modern Security for New (20% effort): Stop recreating legacy patterns

Year 2-3: Complexity Reduction + Modernization - Simplification (40% effort): Product consolidation, system retirement, scope reduction - Modernization (40% effort): Cloud migration, CI/CD, infrastructure-as-code - Essential Security (20% effort): Maintain security during transformation

Year 3-4: Complete Transformation to Visionaries - Security Automation (60% effort): Build Visionary-level capabilities - Legacy Retirement (30% effort): Complete sunset of old systems - Optimization (10% effort): Refine and improve

Expected Outcome: Visionary positioning after 3-4 years

Path B: Increase Readiness Despite Complexity (→ Leaders)¶

Year 1: Stabilize + Hybrid Foundation - Stabilization (40% effort): Quick wins, operational burden reduction - Modern Security for New (40% effort): Break legacy patterns for new systems - Hybrid Strategy (20% effort): Define modern vs. legacy approach

Year 2-3: Gradual Modernization - New Systems (40% effort): Leaders-level capabilities for modern infrastructure - Legacy Pragmatism (30% effort): Managed services, appropriate controls - Platform Capabilities (30% effort): Unified capabilities serving both

Year 4-5: Complete Modernization - Legacy Migration (40% effort): Migrate remaining systems to modern platform - Leaders Capabilities (40% effort): Advanced automation, platform effects - Legacy Retirement (20% effort): Sunset old infrastructure

Expected Outcome: Leaders positioning after 4-5 years (optimistic)

Common Pitfalls¶

Attempting Two-Axis Movement Too Fast¶

Risk: Transformation failure from moving too aggressively

Symptoms: - Multiple simultaneous transformation initiatives - Team burnout from change overload - Incomplete migrations and half-finished modernization - Regression to old patterns under pressure

Solution: Sequence transformation - stabilize first, then move one axis at a time, or reduce complexity before increasing readiness

Underestimating Timeline and Resources¶

Risk: Transformation stalls from insufficient investment

Symptoms: - Transformation "initiatives" without dedicated resources - Security team expected to transform while maintaining BAU - Projects perpetually delayed for operational work - Executive frustration with "slow progress"

Solution: Realistic timelines (years, not months), dedicated resources, executive understanding

Recreating Legacy in Modern Infrastructure¶

Risk: Cloud migration without modernization

Symptoms: - "Lift and shift" cloud migration - Manual processes recreated in cloud environment - Complex security reviews for cloud deployments - Same problems, higher cloud costs

Solution: Modernize during migration, automate from start, break old patterns

Transformation Without Relationship Building¶

Risk: Security transformation fails from engineering resistance

Symptoms: - Security initiatives mandated without buy-in - Engineering teams bypassing security controls - Low adoption of security platforms - Adversarial relationships between security and engineering

Solution: Invest heavily in relationship building, demonstrate value, collaborative approach

Missing the Crisis Window¶

Risk: Transformation loses momentum without executive support

Symptoms: - Transformation deprioritized for short-term needs - Resources pulled for other initiatives - "Transformation fatigue" setting in - Reverting to old patterns

Solution: Use crisis events to secure sustained executive commitment

Success Indicators¶

Year 1 (Stabilization)¶

[ ] Operational burden reduced 20% through automation/elimination
[ ] Executive sponsor actively engaged (monthly transformation reviews)
[ ] Modern security deployed for new systems (not recreating legacy)
[ ] Relationship health improving (measured via engineering satisfaction)
[ ] Transformation roadmap approved with committed resources

Year 2 (Early Transformation)¶

[ ] Operational burden reduced 40% from baseline
[ ] Clear separation between modern and legacy security approaches
[ ] Measurable progress on complexity reduction or modernization
[ ] Team morale stable or improving (not burnout from change)
[ ] Regular executive updates demonstrating progress

Year 3-5 (Transformation Progress)¶

[ ] Operational burden reduced 60-80% from baseline
[ ] Majority of systems on modern infrastructure (or complexity significantly reduced)
[ ] Security automation at Visionary or Leaders level for modern systems
[ ] Sustainable operations (not requiring heroic effort)
[ ] Position movement toward Niche Players, Visionaries, or Leaders

Transformation Success Factors¶

Critical Requirements¶

Executive sponsorship - CEO, CTO, or COO level champion
Realistic timeline - 3-5 years for complete transformation
Dedicated resources - Can't be "side of desk" project
Relationship health - Engineering as partners, not adversaries
Strategic patience - Resist pressure for premature timelines

Helpful Enablers¶

Crisis event creating transformation window
High change capacity in organization
Strong engineering partnership willing to help
Financial resources for tools, cloud migration, hiring
Business support for complexity reduction (if applicable)

Red Flags for Failure¶

"Transform in 12 months" expectations
Security team expected to transform without additional resources
No executive sponsor or inactive sponsor
Damaged relationships with engineering
Attempting transformation during other major changes (M&A, reorgs)

Decision Framework¶

Should You Reduce Complexity First?¶

Yes, if: - You have products/services that could be consolidated or retired - Business model supports scope reduction - Executive support for difficult decisions - Prefer faster transformation (3-4 years vs 4-5 years)

No, if: - Business model requires current complexity - Revenue tied to all current products - No viable consolidation or retirement options - Must maintain all current operations

Can You Successfully Execute Path B (Direct to Leaders)?¶

Realistic if: - Strong executive commitment (CEO level) to 4-5 year timeline - Significant resources available (budget, headcount, time) - High organizational change capacity - Excellent relationship health with engineering - Recent crisis event creating transformation window

Unrealistic if: - Expecting results in 1-2 years - Security team must transform while maintaining full BAU - Damaged relationships with engineering - Low change capacity or change fatigue - No crisis event or executive urgency

If Path B seems unrealistic: Choose Path A (reduce complexity first)

Next Steps¶

Continue to Framework Relationships Back to Niche Players Implementation

Edit this page

Framework Relationships

SF² and NIST SSDF Integration¶

Framework Overview¶

NIST SSDF (Secure Software Development Framework) - Focus: Secure development lifecycle practices - Website: https://csrc.nist.gov/Projects/ssdf - Purpose: High-level guidance for integrating security into software development

Relationship to SF²¶

NIST SSDF tells you WHAT security practices to implement in your software development lifecycle.

SF² tells you HOW to sustainably resource and scale those practices based on your organizational position.

Integration Approach¶

SSDF Provides the Practices¶

NIST SSDF defines four practice groups: 1. Prepare the Organization (PO) - Organizational security culture and training 2. Protect the Software (PS) - Development and build security 3. Produce Well-Secured Software (PW) - Secure design and coding 4. Respond to Vulnerabilities (RV) - Vulnerability management and response

SF² Provides the Implementation Strategy¶

SF² helps you: - Determine which SSDF practices to implement first based on your quadrant position - Choose between manual and automated implementation based on operational readiness - Sequence SSDF practice adoption to avoid overwhelming your organization - Scale SSDF practices sustainably without linear growth in security headcount

Implementation by Quadrant¶

Visionaries (Simple + High Readiness)¶

SSDF Implementation Approach: Automated from the start

Priority SSDF Practices: 1. PS (Protect the Software) - Automated build security, supply chain verification 2. PW (Produce Well-Secured Software) - Automated security testing, secure templates 3. RV (Respond to Vulnerabilities) - Automated dependency scanning and patching 4. PO (Prepare the Organization) - Self-service security documentation

Implementation Strategy: - Automate SSDF practices in CI/CD pipeline from inception - Policy-as-code for SSDF requirements - Self-service SSDF capabilities (developers implement without security review) - Metrics on SSDF practice adoption and effectiveness

Timeline: 6-12 months for comprehensive automated SSDF implementation

Leaders (Complex + High Readiness)¶

SSDF Implementation Approach: Platform-scale automation

Priority SSDF Practices: 1. All SSDF practices at organizational scale with platform effects 2. Advanced automation for complex SSDF requirements 3. Federated SSDF ownership (security champions, guild structure) 4. Continuous SSDF improvement based on metrics

Implementation Strategy: - SSDF practices embedded in internal platforms - Automated evidence collection for SSDF compliance - Organization-wide SSDF metrics and optimization - Industry leadership in SSDF practice innovation

Timeline: Ongoing optimization of established SSDF capabilities

Niche Players (Simple + Low Readiness)¶

SSDF Implementation Approach: Essential practices, pragmatic implementation

Priority SSDF Practices: 1. RV (Respond to Vulnerabilities) - Basic vulnerability management (highest risk) 2. PS (Protect the Software) - Essential build security (supply chain #1 priority) 3. PW (Produce Well-Secured Software) - Secure coding guidelines 4. PO (Prepare the Organization) - Basic security awareness

Implementation Strategy: - Focus on highest-risk SSDF practices first - Use managed services for SSDF capabilities where possible - Manual implementation acceptable at current scale - Avoid over-implementing SSDF practices beyond actual risk

Timeline: 6-12 months for essential SSDF practices

Challengers (Complex + Low Readiness)¶

SSDF Implementation Approach: Hybrid (automated for new, pragmatic for legacy)

Priority SSDF Practices: 1. RV (Respond to Vulnerabilities) - Vulnerability management across complex systems 2. PS (Protect the Software) - Build security for active development 3. Automated SSDF for new systems - Break legacy patterns 4. Pragmatic SSDF for legacy - Risk-based implementation

Implementation Strategy: - Implement automated SSDF for new/modernizing systems - Risk-based SSDF for legacy systems (not full implementation) - Gradual SSDF improvement as systems modernize - Avoid attempting comprehensive SSDF across all systems simultaneously

Timeline: 3-5 years for comprehensive SSDF as systems modernize

Contextual Modifiers and SSDF¶

High Attack Landscape Maturity¶

Impact: Accelerates SSDF RV (Respond to Vulnerabilities) priority - Automated vulnerability scanning becomes critical - Supply chain security (PS) moves to top priority - Manual response processes become existential vulnerability

High Regulatory Constraints¶

Impact: Requires SSDF practice documentation and evidence - Automated evidence collection essential - SSDF compliance reporting becomes significant BAU burden - May require comprehensive SSDF implementation regardless of risk

Crisis Events¶

Impact: Creates window for rapid SSDF adoption - Use incident as catalyst for automated SSDF implementation - "Never waste a good crisis" for securing SSDF resources - Demonstrates clear ROI for SSDF investment

Practical Integration Example¶

Scenario: Series B Startup (Visionary Position)¶

Current State: - Manual security reviews blocking releases - Basic SSDF practices implemented manually - Growing too fast for manual SSDF

SF² Guidance: 1. Assess Position: Visionaries (Simple + High Readiness) 2. Identify Scaling Crisis: Manual SSDF practices not sustainable 3. Constrain BAU: Manual security reviews for novel architectures only 4. Scaling Investment: Automate SSDF practices in CI/CD

SSDF Implementation: - PS (Protect Software): Automated build security, supply chain scanning - PW (Produce Secured Software): Automated SAST/DAST, secure templates - RV (Respond to Vulnerabilities): Automated dependency scanning, patch automation - PO (Prepare Organization): Self-service security documentation

Outcome: SSDF practices fully automated, security reviews reduced 70%

Key Takeaways¶

Use NIST SSDF for: - Comprehensive security practice catalog - Practice descriptions and outcomes - Regulatory compliance requirements - Industry standard terminology

Use SF² for: - Determining which SSDF practices to implement first - Choosing implementation approach (manual vs automated) - Sequencing SSDF adoption based on your position - Scaling SSDF sustainably without linear headcount growth

Together: - SSDF provides the practices - SF² provides the sustainable implementation strategy - Result: Effective security practices at appropriate scale

Next Steps¶

Continue to OWASP SAMM Relationship Back to Implementation Guides

Edit this page

SF² and OWASP SAMM Integration¶

Framework Overview¶

OWASP SAMM (Software Assurance Maturity Model) - Focus: Security practice maturity progression - Website: https://owaspsamm.org/ - Purpose: Assess and improve software security maturity through structured levels

Relationship to SF²¶

OWASP SAMM defines maturity levels (0-3) for security practices across five business functions.

SF² helps determine which maturity levels to pursue and how fast to progress based on your organizational position and readiness.

Key Insight¶

Not every organization should pursue SAMM Level 3 maturity in every practice.

Your SF² quadrant position determines: - Which SAMM practices warrant higher maturity investment - Which practices can remain at lower maturity levels - Speed of maturity progression appropriate for your organization - Whether to pursue breadth (many practices at low maturity) or depth (few practices at high maturity)

SAMM Business Functions¶

OWASP SAMM organizes security practices into five business functions:

Governance - Strategy, metrics, compliance, education
Design - Threat assessment, security requirements, architecture
Implementation - Secure build, deployment, defect management
Verification - Architecture assessment, requirements testing, security testing
Operations - Incident management, environment management, operational enablement

Each practice has maturity levels 0 (not performed) through 3 (optimized/strategic).

SF² Maturity Strategy by Quadrant¶

Visionaries (Simple + High Readiness)¶

SAMM Maturity Approach: High maturity through automation

Target Maturity Levels: - Implementation: Level 3 (fully automated secure build and deployment) - Verification: Level 3 (automated security testing at scale) - Design: Level 2 (automated threat modeling, security requirements) - Operations: Level 2-3 (automated operational security) - Governance: Level 2 (metrics-driven, appropriate documentation)

Maturity Progression Speed: Fast (12-18 months to target state)

Strategy: Automate practices to achieve high maturity quickly - Skip manual maturity levels where possible - Use automation to jump directly to Level 2-3 maturity - Avoid building manual processes that won't scale

Leaders (Complex + High Readiness)¶

SAMM Maturity Approach: Comprehensive high maturity across all functions

Target Maturity Levels: - All practices: Level 2-3 (comprehensive maturity at organizational scale) - Strategic practices: Level 3 with innovation beyond SAMM - Platform effects: Capabilities serving multiple teams

Maturity Progression Speed: Optimization focus (not progression, but refinement)

Strategy: Maintain and optimize high maturity - Continuous improvement of Level 3 practices - Industry leadership in select practices - Efficient maturity maintenance through platform effects - Eliminate practices that don't reduce risk (even if mature)

Niche Players (Simple + Low Readiness)¶

SAMM Maturity Approach: Essential practices at appropriate maturity

Target Maturity Levels: - Implementation: Level 1-2 (basic secure build, essential deployment security) - Verification: Level 1 (basic security testing) - Operations: Level 1 (essential incident response, basic monitoring) - Design: Level 1 (security requirements for high-risk features) - Governance: Level 1 (basic security awareness, minimal documentation)

Maturity Progression Speed: Slow and selective (focus on essentials)

Strategy: Appropriate maturity for scale and risk - Level 1 maturity sufficient for many practices - Invest in higher maturity only for highest-risk areas - Avoid pursuing comprehensive SAMM maturity - Use managed services to achieve maturity without building capability

Challengers (Complex + Low Readiness)¶

SAMM Maturity Approach: Hybrid maturity (high for new, pragmatic for legacy)

Target Maturity Levels by System Type:

New/Modern Systems: - Implementation: Level 2-3 (automated secure build and deployment) - Verification: Level 2 (automated security testing) - Operations: Level 2 (automated operational security)

Legacy Systems: - All practices: Level 1 (basic coverage, risk-based) - Accept lower maturity for systems being retired - Avoid investing in high maturity for legacy

Maturity Progression Speed: Very slow (3-5 years to target state)

Strategy: Build high maturity for future while maintaining basics for legacy - Pursue Level 2-3 maturity for new systems only - Accept Level 0-1 maturity for legacy (pragmatic risk management) - Gradual maturity improvement as systems modernize

Contextual Modifiers and SAMM¶

High Attack Landscape Maturity¶

Impact: Accelerates need for verification and operations maturity - Verification practices must reach Level 2+ (automated security testing) - Operations incident management becomes critical - Manual security testing (Level 1) becomes existential vulnerability

High Regulatory Constraints¶

Impact: Forces governance maturity regardless of risk - Governance practices must reach Level 2 (documentation, metrics, evidence) - Compliance evidence collection becomes significant burden - May require maturity investments that don't align with risk

Low Relationship Health¶

Impact: Slows maturity progression significantly - Difficult to achieve Level 2+ maturity (requires collaboration) - Must invest in relationship building before maturity progression - Forced to rely on Level 1 controls (doesn't require engineering cooperation)

Practical Integration Examples¶

Example 1: Visionary Pursuing SAMM Implementation Maturity¶

Scenario: Series B startup wants to improve secure build practices

Traditional SAMM Approach (Level progression): 1. Level 1: Manual security reviews before builds 2. Level 2: Security requirements documented and reviewed 3. Level 3: Automated security verification in build

SF²-Informed Approach (Skip to automation): 1. Start with Level 3: Implement automated security in CI/CD from the beginning 2. Skip manual levels: Don't build Level 1-2 manual processes 3. Outcome: Level 3 maturity achieved in 6 months vs 18+ months

Example 2: Challenger Pursuing SAMM Verification Maturity¶

Scenario: Large enterprise with mixed legacy and modern systems

Traditional SAMM Approach (Organization-wide): - Attempt Level 2 verification maturity across all systems - Requires significant investment in legacy system testing - Likely to fail or stall

SF²-Informed Approach (Hybrid): - New systems: Pursue Level 2-3 verification (automated testing) - Active legacy: Level 1 verification (basic testing, risk-based) - Retiring legacy: Level 0-1 (accept risk until retirement) - Outcome: Achievable maturity with realistic resources

Example 3: Leaders Optimizing SAMM Governance¶

Scenario: Large tech company with Level 2 governance across the board

Traditional SAMM Approach: - Pursue Level 3 governance for all practices

SF²-Informed Approach (Selective optimization): - Eliminate low-value governance (even if mature) - Optimize high-value governance to Level 3 - Automate governance evidence collection (platform effects) - Outcome: Higher governance effectiveness with less effort

SAMM Maturity Decision Matrix¶

Your SF² Position	SAMM Breadth vs Depth	Target Maturity	Progression Speed
Visionaries	Depth (high maturity in essential practices)	L2-3 for core	Fast (12-18 mo)
Leaders	Comprehensive depth	L2-3 across board	Optimization
Niche Players	Breadth (basic coverage)	L1 sufficient	Slow (essentials only)
Challengers	Hybrid (depth for new, breadth for legacy)	L0-1 legacy, L2-3 new	Very slow (3-5 yr)

Key Takeaways¶

Use OWASP SAMM for: - Comprehensive security practice catalog - Maturity level definitions and assessment - Structured improvement roadmaps - Industry benchmarking

Use SF² for: - Determining which SAMM practices warrant investment - Choosing target maturity levels based on position - Sequencing maturity progression appropriately - Avoiding "maturity for maturity's sake"

Together: - SAMM provides the maturity framework - SF² provides the strategic context for maturity investment - Result: Appropriate maturity for your organizational reality

Critical Insight: Level 3 maturity is not always the goal. SF² helps you determine appropriate maturity levels based on organizational position, operational readiness, and actual risk.

Next Steps¶

Continue to BSIMM Relationship Back to NIST SSDF Relationship

Edit this page

SF² and BSIMM Integration¶

Framework Overview¶

BSIMM (Building Security In Maturity Model) - Focus: Security activity measurement and benchmarking - Website: https://www.bsimm.com/ - Purpose: Describe what real organizations actually do for software security

Relationship to SF²¶

BSIMM describes 112 security activities that organizations perform, organized into 12 practices across 4 domains.

SF² helps determine which BSIMM activities to implement and in what sequence based on your organizational positioning and investment strategy.

Key Insight¶

BSIMM is descriptive, not prescriptive. It shows what organizations do, not what they should do.

SF² provides the strategic framework to: - Prioritize BSIMM activities based on your quadrant position - Sequence BSIMM activity implementation based on investment strategy - Determine which BSIMM activities to skip entirely - Identify when BSIMM activities should be automated vs manual

BSIMM Domains and Practices¶

BSIMM organizes 112 activities into 4 domains:

Governance¶

Strategy & Metrics (SM)
Compliance & Policy (CP)
Training (T)

Intelligence¶

Attack Models (AM)
Security Features & Design (SFD)
Standards & Requirements (SR)

SSDL Touchpoints¶

Architecture Analysis (AA)
Code Review (CR)
Security Testing (ST)

Deployment¶

Penetration Testing (PT)
Software Environment (SE)
Configuration Management & Vulnerability Management (CMVM)

SF² Investment Strategy and BSIMM¶

Visionaries (Simple + High Readiness)¶

BSIMM Activity Selection: Automation-friendly activities that scale

Priority BSIMM Activities: 1. CMVM (Configuration Management & Vulnerability Management) - Automated dependency scanning - Automated vulnerability remediation - Supply chain security automation 2. ST (Security Testing) - Automated SAST/DAST in CI/CD - Security test automation 3. SE (Software Environment) - Automated secure build - Infrastructure-as-code security 4. SFD (Security Features & Design) - Secure templates and paved roads - Automated security patterns

Skip or Minimize: - Manual architecture analysis (AA) - Manual code review (CR) - Extensive governance documentation (CP) - Time-intensive training programs (T) - prefer self-service documentation

Implementation Approach: Automate BSIMM activities from the start

Leaders (Complex + High Readiness)¶

BSIMM Activity Selection: Comprehensive coverage with platform effects

Priority BSIMM Activities: 1. All 12 practices with high activity coverage 2. Platform-scale implementation of BSIMM activities 3. Advanced activities (BSIMM Level 3) appropriate for complexity 4. Federated execution of BSIMM activities (security champions, guilds)

Optimization Focus: - Automate evidence collection for BSIMM activities - Platform capabilities enabling BSIMM activities org-wide - Eliminate low-value BSIMM activities (even if industry performs them) - Industry leadership in select BSIMM practices

Implementation Approach: Comprehensive BSIMM with efficiency focus

Niche Players (Simple + Low Readiness)¶

BSIMM Activity Selection: Essential activities only

Priority BSIMM Activities: 1. CMVM (Configuration Management & Vulnerability Management) - Basic dependency scanning - Vulnerability patching process 2. SR (Standards & Requirements) - Essential security requirements 3. ST (Security Testing) - Basic security testing 4. SE (Software Environment) - Essential build security

Skip Entirely: - Advanced governance activities (SM, CP) - Sophisticated attack modeling (AM) - Manual architecture analysis (AA) - Manual code review (CR) - Penetration testing (PT) - not cost-effective at this scale

Implementation Approach: Minimal BSIMM coverage, managed services where possible

Challengers (Complex + Low Readiness)¶

BSIMM Activity Selection: Hybrid (comprehensive for new, essential for legacy)

Priority BSIMM Activities by System:

New/Modern Systems: - Full BSIMM practice coverage - Automated implementation where possible - Build Leaders-level capabilities for future

Legacy Systems: - CMVM (vulnerability management) only - Essential security testing (ST) - Risk-based approach (not comprehensive)

Skip for Legacy: - Architecture analysis (AA) - legacy is what it is - Code review (CR) - not changing legacy code significantly - Sophisticated attack modeling (AM) - pragmatic risk assessment only

Implementation Approach: Build comprehensive BSIMM for new systems over 3-5 years

BSIMM Activity Prioritization Framework¶

High-Value Activities (Implement First)¶

These BSIMM activities provide highest ROI across all quadrants:

CMVM - Supply chain security and vulnerability management
Highest risk area (Supply Chain #1 priority)
Automatable at all scales
Clear business value
ST - Automated security testing
Scales with automation
Catches issues early (cheaper to fix)
Reduces manual review burden
SE - Secure build environment
Foundation for other activities
Prevents supply chain attacks
Enables automation

Moderate-Value Activities (Implement Selectively)¶

These BSIMM activities have value but require careful sequencing:

SFD - Security features and design
High value for Visionaries (secure templates)
Moderate value for others
SR - Standards and requirements
Essential for regulated environments
Lower priority otherwise
SM - Strategy and metrics
Critical for Leaders (optimization)
Basic for Visionaries
Minimal for Niche Players

Lower-Value Activities (Implement Last or Skip)¶

These BSIMM activities often don't justify their cost:

AA - Architecture analysis
Manual and doesn't scale
Consider skipping for automation instead
CR - Code review
Manual and expensive
Consider automated alternatives (SAST)
T - Training programs
Extensive training doesn't scale
Consider self-service documentation instead
PT - Penetration testing
- Expensive and point-in-time
- Consider continuous automated testing instead

Contextual Modifiers and BSIMM¶

High Attack Landscape Maturity¶

Impact: Prioritizes defensive BSIMM activities - CMVM becomes top priority (automated vulnerability management) - ST must be automated (manual testing too slow) - PT less valuable (adversaries find issues faster than annual pentests)

High Regulatory Constraints¶

Impact: Forces governance BSIMM activities - CP (Compliance & Policy) becomes mandatory - SM (Strategy & Metrics) needed for evidence - T (Training) required for compliance - May require activities that don't reduce actual risk

Low Relationship Health¶

Impact: Limits collaborative BSIMM activities - AA, CR, PT difficult (require engineering cooperation) - Must focus on automated activities (CMVM, ST, SE) - Relationship building becomes prerequisite for manual BSIMM activities

Practical Integration Example¶

Scenario: Challenger Position Enterprise¶

Current State: - Attempting comprehensive BSIMM implementation - Following industry BSIMM scores - Overwhelming security team with 112 activities

Traditional BSIMM Approach: - Implement all activities where industry shows high adoption - Progress through BSIMM levels systematically - Benchmark against similar organizations

SF²-Informed Approach:

Year 1: Stabilization - CMVM automation (Supply Chain #1) - SE for new systems (secure build) - Basic ST (automated security testing) - Skip: AA, CR, PT, extensive T programs

Year 2-3: Hybrid Build-out - New systems: Comprehensive BSIMM (automation-focused) - Legacy: CMVM only (vulnerability management) - Relationship building: Enable collaborative activities (AA, CR) over time

Year 4-5: Comprehensive Coverage - Full BSIMM for modernized systems - Retire legacy activities as systems sunset - Optimize: Eliminate low-value activities

Outcome: Achievable BSIMM implementation aligned with transformation timeline

BSIMM Activity Decision Matrix¶

Your SF² Position	BSIMM Activity Count	Implementation Focus	Automation Level
Visionaries	30-40 activities	Automation-friendly activities	Very high
Leaders	60-80 activities	Comprehensive with efficiency	High
Niche Players	15-25 activities	Essential only	Managed services
Challengers	30-40 (new systems only)	Hybrid approach	Mixed

Note: These are guidelines, not targets. More BSIMM activities doesn't necessarily mean better security.

Key Takeaways¶

Use BSIMM for: - Comprehensive catalog of security activities - Understanding what other organizations do - Benchmarking your security program - Identifying potential activity gaps

Use SF² for: - Prioritizing which BSIMM activities to implement - Sequencing BSIMM activity adoption - Determining automation vs manual implementation - Deciding which BSIMM activities to skip entirely

Together: - BSIMM provides the activity catalog - SF² provides the strategic prioritization framework - Result: Focused security program aligned with organizational reality

Critical Insight: More BSIMM activities doesn't equal better security. SF² helps you implement the right BSIMM activities for your organization, not the most activities.

Next Steps¶

Continue to OWASP ASVS Relationship Back to OWASP SAMM Relationship

Edit this page

SF² and OWASP ASVS Integration¶

Framework Overview¶

OWASP ASVS (Application Security Verification Standard) - Focus: Security verification requirements for applications - Website: https://owasp.org/www-project-application-security-verification-standard/ - Purpose: Comprehensive security requirements for testing web applications

Relationship to SF²¶

OWASP ASVS provides comprehensive security verification requirements organized into 14 categories across 3 verification levels.

SF² helps determine which ASVS level to target, which requirements to prioritize, and how to implement verification based on organizational position and risk.

Key Insight¶

ASVS provides three verification levels: - Level 1 (Opportunistic): Basic security for low-risk applications - Level 2 (Standard): Most applications should meet this level - Level 3 (Advanced): High-security applications with stringent requirements

SF² helps you determine: - Which ASVS level is appropriate for your organization - Whether to implement comprehensive ASVS or risk-based subset - How to sequence ASVS requirement implementation - Whether to automate or manually verify ASVS requirements

ASVS Verification Categories¶

ASVS organizes requirements into 14 categories:

Architecture, Design and Threat Modeling
Authentication
Session Management
Access Control
Validation, Sanitization and Encoding
Stored Cryptography
Error Handling and Logging
Data Protection
Communication
Malicious Code
Business Logic
Files and Resources
API and Web Service
Configuration

SF² ASVS Strategy by Quadrant¶

Visionaries (Simple + High Readiness)¶

ASVS Verification Approach: Automated Level 2, selective Level 3

Target ASVS Level: Level 2 (Standard) for most applications

Implementation Strategy: - Automate ASVS verification in CI/CD pipeline - Automated testing for ASVS categories that support automation: - V5 (Validation, Sanitization) - SAST/DAST - V7 (Error Handling and Logging) - Automated scanning - V9 (Communication) - TLS/certificate verification - V13 (API and Web Service) - API security testing - Secure templates implementing ASVS requirements by default - Self-service ASVS verification for developers

Manual Verification (for requirements that can't be automated): - V1 (Architecture and Threat Modeling) - Risk-based for novel architectures - V4 (Access Control) - Logic testing for complex authorization - V11 (Business Logic) - Application-specific verification

Timeline: 12-18 months to comprehensive automated ASVS Level 2

Leaders (Complex + High Readiness)¶

ASVS Verification Approach: Comprehensive Level 2, selective Level 3 for high-risk

Target ASVS Level: - Level 2 (Standard) for all applications - Level 3 (Advanced) for high-security applications (payment, sensitive data, critical infrastructure)

Implementation Strategy: - Platform-scale ASVS verification serving multiple teams - Automated ASVS testing integrated into security platforms - Security product capabilities (if customer-facing software factory) - ASVS compliance as competitive advantage - Automated customer-facing security verification reports - Advanced verification for complex requirements - Automated threat modeling capabilities - Sophisticated access control testing

Optimization Focus: - Automated evidence collection for ASVS compliance - Continuous ASVS verification (not point-in-time) - Industry leadership in ASVS automation

Timeline: Ongoing optimization of established ASVS capabilities

Niche Players (Simple + Low Readiness)¶

ASVS Verification Approach: Essential Level 1 requirements, risk-based Level 2

Target ASVS Level: Level 1 (Opportunistic) baseline, selective Level 2 for high-risk areas

Implementation Strategy: - Focus on highest-risk ASVS categories: - V2 (Authentication) - Critical for all applications - V3 (Session Management) - Essential security baseline - V5 (Validation, Sanitization) - Prevent common vulnerabilities - V9 (Communication) - TLS/HTTPS basics - Use managed security services that provide ASVS compliance - Basic security testing covering essential ASVS requirements - Accept Level 1 compliance for lower-risk areas

Skip or Minimize: - Advanced ASVS categories (Architecture, Business Logic) - Comprehensive Level 2 verification for low-risk functionality - Level 3 requirements (not cost-effective at this scale)

Timeline: 6-12 months to essential ASVS Level 1 coverage

Challengers (Complex + Low Readiness)¶

ASVS Verification Approach: Hybrid (Level 2 for new, Level 1 for legacy)

Target ASVS Level by System:

New/Modern Applications: - Level 2 (Standard) with automated verification - Build Visionary/Leaders-level ASVS capabilities for future

Active Legacy Applications: - Level 1 (Opportunistic) baseline - Risk-based Level 2 for critical functionality - Accept pragmatic risk for legacy

Legacy Applications Being Retired: - Level 1 or accept known gaps - Don't invest in comprehensive ASVS for retiring systems

Implementation Strategy: - Automated ASVS for new application development - Pragmatic risk assessment for legacy applications - Gradual ASVS improvement as applications modernize - Hybrid verification tools that work across modern and legacy

Timeline: 3-5 years to comprehensive Level 2 as applications modernize

Risk-Based ASVS Prioritization¶

Critical ASVS Categories (All Organizations)¶

These categories should be prioritized regardless of position:

V2 (Authentication) - Broken authentication = complete compromise
V3 (Session Management) - Session attacks affect all applications
V4 (Access Control) - Broken access control = unauthorized access
V5 (Validation, Sanitization) - Prevents injection attacks

High-Value ASVS Categories (Visionaries, Leaders, Challengers-New)¶

V9 (Communication) - TLS/encryption for data in transit
V8 (Data Protection) - Sensitive data handling
V13 (API and Web Service) - API security increasingly critical

Moderate-Value ASVS Categories (Situational)¶

V6 (Stored Cryptography) - If handling sensitive data
V7 (Error Handling and Logging) - Incident response needs
V14 (Configuration) - Security misconfiguration prevention

Lower-Value ASVS Categories (Deprioritize)¶

V1 (Architecture, Design, Threat Modeling) - Time-intensive, hard to automate
V11 (Business Logic) - Application-specific, manual verification
V10 (Malicious Code) - Covered by supply chain security
V12 (Files and Resources) - Lower risk for modern applications

Contextual Modifiers and ASVS¶

High Attack Landscape Maturity¶

Impact: Accelerates need for comprehensive ASVS - Level 2 becomes minimum even for simple applications - Automated ASVS verification essential (manual testing too slow) - Continuous verification (not annual assessments)

High Regulatory Constraints¶

Impact: May require comprehensive Level 2 or Level 3 - PCI DSS, HIPAA, SOC 2 often reference ASVS - Level 3 verification may be mandated for regulated data - Evidence collection for ASVS compliance becomes significant burden

Customer-Facing Software Factory¶

Impact: ASVS becomes competitive advantage - ASVS Level 2+ compliance as trust signal to customers - Security verification reports based on ASVS - Industry certifications (OWASP, CSA) requiring ASVS

Practical Integration Examples¶

Example 1: Visionary SaaS Startup¶

Scenario: Series B startup building SaaS platform

Traditional ASVS Approach: - Annual penetration test checking ASVS requirements - Manual verification of ASVS categories - Expensive and point-in-time

SF²-Informed Approach: - Automated ASVS verification in CI/CD: - SAST/DAST covering V5, V7, V9, V13 - Automated authentication testing (V2, V3) - TLS/certificate validation (V9) - Secure templates implementing ASVS requirements by default - Manual verification only for V1, V4, V11 (architecture, access control, business logic) - Continuous ASVS verification with every deployment

Outcome: Level 2 ASVS compliance with 80% automation, continuous verification

Example 2: Challenger Financial Services¶

Scenario: Large bank with legacy applications and modern cloud services

Traditional ASVS Approach: - Attempt Level 3 ASVS across all applications - Comprehensive manual verification - Overwhelming security team

SF²-Informed Approach: - New cloud services: Level 2 ASVS with automated verification - Critical legacy: Level 2 for V2-V5 (authentication, access control, validation) - Non-critical legacy: Level 1 baseline, accept gaps - Retiring applications: No new ASVS investment

Outcome: Achievable ASVS compliance aligned with modernization timeline

Example 3: Leaders Platform Company¶

Scenario: Large tech company with security product capabilities

Traditional ASVS Approach: - Comprehensive Level 2-3 ASVS verification - Significant manual verification effort

SF²-Informed Approach: - Automated ASVS platform serving all teams: - Security testing platform covering ASVS requirements - Self-service ASVS verification for developers - Automated compliance reporting - Advanced verification capabilities: - Automated threat modeling (V1) - Sophisticated access control testing (V4) - Customer-facing ASVS compliance: - Security verification reports based on ASVS - Competitive advantage through security transparency

Outcome: Comprehensive ASVS Level 2-3 with platform efficiency, security as differentiator

ASVS Level Decision Matrix¶

Your SF² Position	Target ASVS Level	Verification Approach	Coverage
Visionaries	Level 2	Automated verification	Comprehensive for new
Leaders	Level 2-3	Platform-scale automation	Comprehensive all apps
Niche Players	Level 1	Managed services, basic testing	Essential categories
Challengers	Level 1-2 hybrid	Automated for new, risk-based for legacy	New: L2, Legacy: L1

Key Takeaways¶

Use OWASP ASVS for: - Comprehensive security verification requirements - Standard terminology for security testing - Compliance and certification requirements - Technical security testing guidance

Use SF² for: - Determining appropriate ASVS level for your organization - Prioritizing ASVS requirements based on risk - Sequencing ASVS implementation within investment strategy - Choosing automation vs manual verification approach

Together: - ASVS provides the verification requirements - SF² provides the implementation strategy - Result: Risk-appropriate security verification at sustainable scale

Critical Insights: - Level 3 ASVS is not always necessary - Most applications should target Level 2 - Not all ASVS requirements are equal - Prioritize based on risk - Automation accelerates ASVS adoption - Don't rely solely on manual verification - Hybrid approaches work - Different ASVS levels for different system types

Next Steps¶

You've completed the Framework Relationships section! Continue to Use Cases or explore the Appendix:

View Use Cases Back to BSIMM Relationship Explore Glossary

Edit this page

Use Cases and Application Scenarios¶

Applying SF² to Real-World Situations¶

This section demonstrates how to apply the Software Factory Security Framework to common organizational scenarios. Each use case shows how the framework's components work together to guide strategic decisions.

Use Case 1: Scaling Crisis at Series B Startup¶

Situation¶

A 50-person SaaS startup (Visionary position) hits the scaling crisis: security reviews now take 2 weeks, blocking feature releases.

Framework Application¶

Strategic Position: Visionaries (Simple + High Readiness)

Contextual Modifiers: - High attack landscape maturity (SaaS target) - Moderate supply chain complexity (standard dependencies) - Strong relationship health (good dev-security collaboration)

Investment Strategy: 1. Constrain BAU: Reduce manual security reviews to critical features only 2. Scaling Investment: Implement automated security scanning + paved roads for common patterns 3. Timeline: 6-month implementation with 3x ROI expected

Outcome: Security reviews reduced from 2 weeks to 2 hours for standard patterns; manual reviews only for novel architectures.

Use Case 2: Enterprise Undergoing Digital Transformation¶

Situation¶

A 5,000-person financial services company (Challenger position) needs to modernize security while maintaining compliance and managing legacy systems.

Framework Application¶

Strategic Position: Challengers (Complex + Low Readiness)

Contextual Modifiers: - High regulatory constraints (financial services) - Low change capacity (risk-averse culture) - Moderate relationship health (improving) - Recent crisis event (audit findings)

Investment Strategy: 1. Use crisis window: Leverage audit findings for funding approval 2. Hybrid approach: Modern security for new systems, pragmatic controls for legacy 3. Extended timeline: 36-48 month transformation with phased rollout

Outcome: Gradual modernization with compliance maintained; crisis event created sustainable funding for transformation.

Use Case 3: Supply Chain Attack Response¶

Situation¶

A technology company discovers compromised dependencies used in production systems, triggering supply chain security overhaul.

Framework Application¶

Universal Stewardship Priority: Supply Chain #1 priority activated

Contextual Modifiers: - High attack landscape maturity (automated supply chain attacks) - Crisis event (compromised dependency) - Complex supply chain (multi-tier dependencies)

Response Strategy: 1. Immediate: Contain and assess impact 2. Short-term: Implement automated dependency scanning 3. Medium-term: Deploy SBOM capabilities and continuous monitoring 4. Long-term: Build supply chain security platform

Outcome: Supply chain visibility improved from quarterly manual audits to continuous automated monitoring.

Use Case 4: Moving from Niche Player to Visionary¶

Situation¶

A 20-person startup with legacy infrastructure decides to modernize their entire stack to enable faster growth.

Framework Application¶

Current Position: Niche Players (Simple + Low Readiness) Target Position: Visionaries (Simple + High Readiness)

Movement Path: Infrastructure modernization (single axis movement) - Timeline: 12-18 months - Success probability: High (single axis change)

Investment Priorities: 1. Cloud platform migration 2. CI/CD automation 3. Infrastructure-as-code 4. Automated security testing

Security Integration: - Implement security automation during modernization - Policy-as-code from the start - Avoid recreating manual processes in new infrastructure

Outcome: Successful transformation with security embedded in modern infrastructure from inception.

Use Case 5: BAU Constraint Implementation¶

Situation¶

A security team at series C company recognizes unsustainable demand growth and needs to shift from manual security reviews to scaling approach.

Framework Application¶

BAU Constraint Strategy (from Investment Portfolio):

Phase 1 - Communication (Month 1): - Transparent explanation of scaling challenge - Presentation of self-service alternatives - Clear prioritization criteria for manual reviews

Phase 2 - Alternatives (Months 2-3): - Deploy security scanning automation - Create secure templates for common patterns - Build self-service documentation

Phase 3 - Constraint (Month 4): - Limit manual reviews to novel/high-risk changes - Direct teams to self-service for standard patterns - Measure adoption and iterate

Outcome: Manual security reviews reduced 70%; security coverage improved through automation; developer satisfaction increased.

Framework Application Template¶

Use this template to apply SF² to your organization:

1. Assess Strategic Position¶

Operational Complexity: Simple / Complex
Operational Readiness: Lower / Higher
Current Quadrant: ___

2. Evaluate Contextual Modifiers¶

Modifier	Level (Low/Moderate/High)	Impact
Attack Landscape
Supply Chain Complexity
Regulatory Constraints
Crisis Events
Change Capacity
Relationship Health

3. Identify Priority Stewardship Areas¶

Based on position and modifiers: 1. Primary focus: __ 2. Secondary focus: __ 3. Maintenance areas: ___

4. Design Investment Portfolio¶

BAU to constrain: ___
Scaling investments: ___
Timeline: ___
Expected outcomes: ___

5. Plan Movement Path (if applicable)¶

Current position: ___
Target position: ___
Movement strategy: ___
Timeline: ___

Contributing Use Cases¶

Have you applied SF² to your organization? We welcome real-world use case contributions!

What to include: - Organizational context (anonymized) - Strategic position and modifiers - Framework application approach - Outcomes and lessons learned - Advice for similar situations

How to contribute: See Contributing Guidelines

Next Steps¶

Explore Framework Relationships Back to Implementation Guides

AI Integration

AI-Assisted Strategic Planning with SF²¶

Why AI Tools for Security Strategy?¶

Modern AI assistants (Claude, ChatGPT, Gemini) can significantly accelerate security strategy work when properly configured with the SF² framework. They're particularly effective for:

Strategic analysis - Assessing your organizational position
Investment prioritization - Determining which capabilities to build first
Scenario planning - Exploring transformation paths and timelines
Framework application - Translating SF² concepts to your specific context
Executive communication - Drafting board-ready strategy documents

Key Capabilities of AI Assistants¶

Context Management¶

Modern AI tools support various context management features:

Claude Desktop: Projects with persistent knowledge bases
ChatGPT: Custom GPTs with specific instructions and knowledge
Gemini: Gems with customized personas and knowledge

Strategic Advantages¶

1. Framework Internalization - Load SF² framework documentation into AI context - Get instant guidance on quadrant positioning and investment strategy - Explore framework application to your specific situation

2. Decision Support - Analyze your organization against framework dimensions - Compare strategic options with framework-informed analysis - Model transformation timelines and resource requirements

3. Communication Acceleration - Draft strategy documents aligned with SF² concepts - Generate executive summaries with framework terminology - Create board presentations explaining strategic positioning

4. Continuous Reference - Always-available framework consultation - Consistent strategic vocabulary across your team - Rapid exploration of "what-if" scenarios

How to Use This Section¶

This section provides practical guidance for integrating SF² with popular AI tools:

Claude Integration - Claude Projects, custom instructions, example workflows
ChatGPT Integration - Custom GPTs, system prompts, practical examples
Gemini Integration - Gems configuration, custom instructions, use cases

Each guide includes: - Setup instructions for the specific platform - Framework-specific prompts and instructions - Example conversations demonstrating strategic analysis - Practical workflows for common security leader tasks

General Best Practices¶

1. Start with Your Position Assessment¶

Initial Prompt Template:

I'm a security leader at [company description]. Help me assess our SF² position:

Operational Complexity: [simple/complex]
- Team size: [X engineers]
- Products/services: [description]
- Infrastructure: [description]

Operational Readiness: [lower/higher]
- CI/CD maturity: [description]
- Automation level: [description]
- Infrastructure type: [cloud/hybrid/on-prem]

What quadrant are we in, and what should be our strategic priorities?

2. Explore Contextual Modifiers¶

Follow-up Analysis:

Analyze how these contextual modifiers affect our strategy:

- Attack landscape maturity: [high/moderate/low]
- Supply chain complexity: [description]
- Regulatory constraints: [requirements]
- Recent crisis events: [if any]
- Change capacity: [high/moderate/low]
- Relationship health with engineering: [strong/functional/damaged]

How do these modifiers influence our investment priorities?

3. Develop Investment Strategy¶

Strategic Planning Prompt:

Based on our [quadrant] position, help me design a 12-month investment strategy:

Current BAU activities consuming team time:
- [list manual security work]

Available resources:
- Team: [size and composition]
- Budget: [if relevant]
- Executive support: [level]

What scaling investments should we prioritize?

4. Create Transformation Roadmap¶

Roadmap Development:

We're planning to move from [current position] to [target position].

Timeline: [X months/years]
Resources: [available]
Constraints: [regulatory, organizational, technical]

Create a realistic transformation roadmap with:
- Major milestones
- Success indicators
- Risk factors
- Resource requirements

Strategic Use Cases for AI Assistance¶

Board Preparation¶

Scenario: Need to brief the board on security strategy

AI Workflow: 1. Load current organizational assessment 2. Request executive summary using SF² positioning 3. Generate visual explanations of investment strategy 4. Draft talking points for strategic transitions 5. Prepare answers to anticipated board questions

Budget Justification¶

Scenario: Need to justify security investments

AI Workflow: 1. Explain current position and scaling crisis 2. Generate ROI analysis for scaling investments 3. Draft budget proposal using SF² terminology 4. Create comparison of BAU vs scaling investment outcomes 5. Prepare responses to CFO concerns

Organizational Assessment¶

Scenario: New security leader wants to understand organizational positioning

AI Workflow: 1. Systematic assessment of operational complexity 2. Evaluation of operational readiness maturity 3. Analysis of contextual modifiers 4. Strategic recommendations based on positioning 5. Priority action plan for first 90 days

Vendor Evaluation¶

Scenario: Deciding which security tools to purchase

AI Workflow: 1. Map tools to SF² investment categories (BAU vs scaling) 2. Evaluate tool fit for your quadrant position 3. Analyze whether tools support automation or create manual work 4. Compare tools against strategic priorities 5. Generate vendor evaluation criteria aligned with framework

Team Communication¶

Scenario: Need to explain strategic direction to security team

AI Workflow: 1. Translate SF² concepts into team-accessible language 2. Generate examples relevant to your organization 3. Draft all-hands presentation on strategy 4. Create FAQ addressing common concerns 5. Develop communication plan for transformation

Privacy and Security Considerations¶

Safe to include: - Framework concepts and terminology - General organizational characteristics (size, complexity) - Strategic objectives and investment priorities - Hypothetical scenarios and planning discussions - Public information about your organization

Avoid including: - Specific vulnerability details - Actual security incidents and response details - Confidential business information - Customer or user data - Proprietary technical implementations - Security tool configurations and policies

Data Handling by Platform¶

Claude Desktop: - Projects stored locally with optional cloud sync - Can be used in offline mode for sensitive work - Supports organizational deployment with data controls

ChatGPT: - Custom GPTs available for Team and Enterprise plans - Enterprise plans offer enhanced data privacy - Can disable training on your conversations

Gemini: - Gems available with privacy controls - Enterprise plans offer data residency options - Activity controls available for privacy management

Recommended Approach¶

Use for strategy, not tactics: Focus on strategic positioning and investment planning rather than tactical security details
Abstract when necessary: Use "Organization A" instead of your company name if concerned
Review outputs: Always review AI-generated content before sharing internally
Enterprise accounts: Consider enterprise AI accounts for enhanced privacy controls

Framework Update Strategy¶

As SF² evolves, keep your AI context current:

Monitor framework updates: Check the GitLab repository for new releases
Update AI context: Refresh your Projects/GPTs/Gems with new framework versions
Test updated guidance: Verify AI responses align with latest framework thinking
Share improvements: Contribute back useful prompts and workflows

Next Steps¶

Choose your AI platform to get started:

Claude Integration Guide ChatGPT Integration Guide Gemini Integration Guide

Back to Use Cases

Edit this page

Claude Integration for SF² Strategic Planning¶

Why Claude for Security Strategy?¶

Claude excels at strategic analysis and long-form reasoning, making it particularly well-suited for security leadership work:

Deep context understanding - Handles complex organizational situations
Nuanced analysis - Balances competing priorities and tradeoffs
Professional communication - Executive-ready output
Long conversations - Extended strategic planning sessions
Projects feature - Persistent framework knowledge base

Setup: Claude Projects¶

Creating an SF² Strategy Project¶

Claude Desktop: Projects → New Project

Project Name: SF² Security Strategy

Project Instructions:

You are a strategic security advisor helping me apply the Software Factory Security Framework (SF²) to my organization.

## Your Role
- Help assess our current SF² quadrant position
- Guide investment strategy decisions
- Analyze contextual modifiers and their impact
- Develop transformation roadmaps
- Draft executive communications

## Framework Principles
- Supply Chain Stewardship is #1 priority (due to adversary evolution to automated discovery)
- BAU activities should be constrained, not expanded
- Scaling investments create compound capabilities
- Operational readiness determines automation feasibility
- Contextual modifiers significantly affect strategy
- Two-axis transformation is high-risk

## Communication Style
- Strategic and pragmatic
- Direct about tradeoffs and risks
- Executive-appropriate language
- Data-informed recommendations
- Clear prioritization and sequencing

## Always Consider
1. Which SF² quadrant is this organization in?
2. What contextual modifiers apply?
3. Is this BAU work (to constrain) or scaling investment?
4. What's the realistic timeline?
5. What are the transformation risks?

Adding Framework Documentation¶

Project Knowledge:

Add this website: https://sf2framework.com
Claude can read and reference the complete framework
Or add specific framework sections as text documents:
Foundation and core concepts
Your quadrant's implementation guide
Relevant framework relationships (NIST SSDF, OWASP SAMM, etc.)
Add your organizational context:
Current organizational assessment
Team structure and capabilities
Existing investments and constraints
Strategic objectives

Strategic Workflows¶

Workflow 1: Position Assessment¶

Initial Message:

Help me assess our SF² position:

Company: [Describe your organization]
- Engineering team size: [number]
- Products/services: [description]
- Revenue stage: [series B, public, etc.]

Infrastructure:
- Platform: [AWS/GCP/Azure, on-prem, hybrid]
- CI/CD: [mature/developing/manual]
- Automation level: [high/moderate/low]
- Architecture: [cloud-native/transitioning/legacy]

Security team:
- Size: [number]
- Current focus: [what you do today]
- Biggest pain points: [manual work, bottlenecks]

What's our quadrant position and what should we prioritize?

Claude Response Pattern: - Analyzes operational complexity factors - Evaluates operational readiness indicators - Determines quadrant positioning - Identifies applicable contextual modifiers - Provides strategic recommendations

Workflow 2: Investment Planning¶

Planning Prompt:

Based on our [quadrant] position, help me plan our next 12 months:

Current BAU consuming most time:
1. [Manual security reviews - 40% of team time]
2. [Vulnerability triage - 25% of team time]
3. [Compliance reporting - 15% of team time]

Available resources:
- Security team: [X people with Y skill mix]
- Budget for tools/platforms: [$Z or limited/moderate/significant]
- Engineering partnership: [strong/developing/needs work]
- Executive support: [high/moderate/uncertain]

Constraints:
- [Regulatory requirements]
- [Technical debt/legacy systems]
- [Organizational change capacity]

Design our investment strategy with specific priorities.

Claude Analysis: - Maps current work to BAU vs scaling categories - Identifies highest-leverage automation opportunities - Sequences investments based on dependencies - Estimates timelines and success probability - Highlights risks and mitigation strategies

Workflow 3: Executive Communication¶

Communication Request:

Draft a board slide on our security strategy using SF² positioning:

Context:
- Board is concerned about: [security incidents, growth, compliance]
- They understand: [what board knows about security]
- Time allocation: [5 minutes / single slide / 15-minute deep dive]

Our strategy:
- Current position: [quadrant]
- Scaling crisis: [description of unsustainable manual work]
- Investment approach: [what we're building]
- Expected outcomes: [metrics and timeline]

Make it board-appropriate with clear business value.

Claude Deliverable: - Executive-appropriate summary - Clear problem statement and solution - Business value articulation - Risk-balanced presentation - Anticipated questions and answers

Workflow 4: Framework Application to Specific Decision¶

Decision Analysis:

We're deciding whether to [specific decision, e.g., "build vs buy security platform"].

Option A: [Description]
- Pros: [list]
- Cons: [list]
- Investment: [resources required]

Option B: [Description]
- Pros: [list]
- Cons: [list]
- Investment: [resources required]

Apply SF² framework: which option aligns with our [quadrant] position and strategic priorities?

Claude Analysis: - Maps options to BAU vs scaling investment categories - Evaluates alignment with quadrant-specific priorities - Considers contextual modifiers - Analyzes compound capability potential - Provides framework-grounded recommendation

Workflow 5: Transformation Planning¶

Roadmap Development:

We're planning to move from [current quadrant] to [target quadrant]:

Timeline: [how long we have]
Resources: [what we can commit]
Constraints: [what limits us]
Risk tolerance: [high/moderate/low]

Create a realistic transformation roadmap with:
- Major phases and milestones
- Success indicators at 6/12/24 months
- Resource requirements per phase
- Risk factors and mitigation
- Decision points and criteria

Claude Roadmap: - Phased approach with clear milestones - Realistic timelines based on complexity - Success indicators tied to framework positioning - Risk assessment with contingency planning - Clear decision criteria for go/no-go moments

Advanced Usage Patterns¶

Multi-Turn Strategic Planning Sessions¶

Claude excels at extended conversations. Use this for:

Session 1: Discovery and Assessment (30-60 minutes) - Explore organizational context - Assess quadrant positioning - Identify contextual modifiers - Clarify strategic objectives

Session 2: Investment Strategy (45-90 minutes) - Analyze current BAU activities - Identify scaling investment opportunities - Prioritize and sequence investments - Develop success metrics

Session 3: Roadmap and Communication (30-60 minutes) - Create transformation roadmap - Draft executive communications - Prepare board materials - Plan team communications

Using Claude for Framework Learning¶

Learning Conversation Pattern:

I'm new to the SF² framework. Walk me through:

1. The core concept of [specific topic]
2. Why this matters for security leaders
3. How to apply this to my [organizational context]
4. Common pitfalls to avoid
5. Success indicators

Use my organization as examples to make it concrete.

Benefits: - Personalized framework education - Context-specific examples - Interactive Q&A - Practical application focus

Comparative Analysis¶

Framework Comparison:

Compare how SF² would guide our approach vs [traditional approach/different framework]:

Scenario: [specific situation]

Traditional approach:
[describe conventional wisdom]

SF² approach:
[apply framework positioning]

What's different, why does it matter, and what are the tradeoffs?

Example Strategic Planning Conversation¶

Part 1: Initial Assessment¶

You:

Help me assess our position. We're a Series B SaaS company with 150 engineers across 3 product teams. Infrastructure is cloud-native (AWS), we have solid CI/CD, but security reviews are blocking releases. Security team of 5 people spending 60% of time on manual security reviews.

Claude:

Based on your description, you're positioned as **Visionaries** (Simple + High Readiness):

Operational Complexity: Simple
- 150 engineers is moderate scale
- 3 product teams is manageable
- Single platform (AWS cloud-native)

Operational Readiness: High
- Cloud-native infrastructure
- Solid CI/CD foundation
- Modern tech stack

Critical Issue: You're at the **scaling crisis**
- 60% of security team time on manual reviews is unsustainable
- This will only get worse as you grow
- You're positioned to solve this through automation

Strategic Priority: Constrain BAU, invest in scaling
- Reduce manual reviews through automation
- Build paved roads for common patterns
- Self-service security capabilities

This is actually an ideal position - you have the readiness to automate effectively.

Shall we design your investment strategy?

Part 2: Investment Strategy¶

You:

Yes. Main BAU activities:
- Security reviews (60%)
- Vulnerability triage (20%)
- Compliance work (15%)
- Other (5%)

What should we automate first?

Claude:

Priority Investment Sequence for Visionaries:

**Phase 1 (Months 1-3): Security Review Automation**
Invest 70% of time in automation, constrain reviews to 30%:

1. Deploy automated security scanning:
   - SAST/DAST integrated into CI/CD
   - Dependency/supply chain scanning (Supply Chain #1!)
   - Container security scanning

2. Create secure templates:
   - Identify 3 most common architecture patterns
   - Build pre-approved secure templates
   - Self-service for standard patterns

3. Triage criteria:
   - Manual review only for novel architectures
   - Everything else uses automation + templates

Expected outcome: Security reviews drop from 60% to 20% of time

**Phase 2 (Months 4-6): Vulnerability Automation**
Redirect saved time to vulnerability management:

1. Automated vulnerability scanning and prioritization
2. Auto-patching for approved dependency updates
3. SLA-driven vulnerability remediation workflow

Expected outcome: Vulnerability triage drops from 20% to 5%

**Phase 3 (Months 7-12): Scaling Further**
With 50% time saved, invest in:

1. Advanced security automation
2. Security champions program (distribute knowledge)
3. Policy-as-code capabilities

This sequence:
- Addresses your biggest pain point first (reviews)
- Leverages your high operational readiness
- Creates compound capabilities (each builds on previous)
- Realistic for 12-month timeline with your team

Shall we detail Phase 1 implementation?

Tips for Effective Claude Usage¶

1. Provide Rich Context¶

Don't assume Claude remembers everything (even in Projects)
Restate key context when starting new conversation threads
Be specific about organizational constraints

2. Ask for Reasoning¶

Explain your framework-based reasoning for this recommendation.
Why is this the right approach for our quadrant position?

3. Request Alternatives¶

What would be different if we were [different quadrant]?
What are alternative approaches and their tradeoffs?

4. Iterate on Output¶

Make this more [concise/detailed/executive-friendly]
Focus more on [specific aspect]
Add [specific element]

5. Use for Scenario Planning¶

What if [contextual modifier changes]?
How would this recommendation change if [constraint added]?
Model best-case and worst-case timelines.

Claude Desktop Advantages¶

Persistent Projects¶

Framework knowledge always available
Organizational context maintained
Strategic continuity across conversations

Privacy Controls¶

Projects stored locally by default
Can be used offline for sensitive planning
No training on your conversations (Anthropic policy)

Long Context¶

Handle complex organizational situations
Extended strategic planning sessions
Reference lengthy framework documentation

File Uploads¶

Upload organizational assessments
Analyze existing strategy documents
Process team surveys and feedback

Next Steps¶

See ChatGPT Integration See Gemini Integration Back to AI Integration Overview

Edit this page

ChatGPT Integration for SF² Strategic Planning¶

Why ChatGPT for Security Strategy?¶

ChatGPT offers unique advantages for security leadership work:

Custom GPTs - Purpose-built assistants with framework knowledge
Broad availability - Widely adopted in enterprises
Plugin ecosystem - Extensible with additional capabilities
Team collaboration - Share custom GPTs with your organization
Enterprise features - Enhanced privacy and data controls

Setup: Custom GPTs¶

Creating an SF² Strategy GPT¶

Requirements: ChatGPT Plus, Team, or Enterprise

Steps: Explore GPTs → Create → Configure

GPT Configuration¶

Name: SF² Security Strategy Advisor

Description:

Strategic security advisor using the Software Factory Security Framework (SF²) to help security leaders assess organizational positioning, design investment strategies, and plan transformations.

Instructions:

You are a strategic security advisor specializing in the Software Factory Security Framework (SF²).

## Your Expertise
The SF² framework helps security leaders scale security capabilities while improving business outcomes through:
- Two-axis positioning model (Operational Complexity × Operational Readiness)
- Four quadrant strategic positions (Visionaries, Leaders, Niche Players, Challengers)
- Universal stewardship areas with Supply Chain as #1 priority
- Investment portfolio framework (BAU to constrain, Scaling investments to build)
- Six contextual modifiers affecting implementation

## Your Role
Help security leaders:
1. Assess their current SF² quadrant position
2. Analyze contextual modifiers affecting strategy
3. Design appropriate investment strategies
4. Develop realistic transformation roadmaps
5. Draft executive communications

## Core Principles
- Supply Chain Stewardship is #1 priority (due to adversary evolution to automated discovery)
- Constrain BAU activities, don't expand them
- Scaling investments create compound capabilities
- High operational readiness enables automation
- Two-axis transformation is high-risk, requires sequencing
- Appropriate security depends on organizational position

## Assessment Approach
When assessing an organization:
1. Determine operational complexity (team size, products, infrastructure)
2. Evaluate operational readiness (automation, CI/CD, infrastructure maturity)
3. Map to quadrant position (Visionaries/Leaders/Niche Players/Challengers)
4. Identify applicable contextual modifiers
5. Provide quadrant-specific strategic recommendations

## Strategic Recommendations
- Visionaries: Automate early, build scaling foundations
- Leaders: Optimize existing, platform effects, competitive advantage
- Niche Players: Choose intentional simplicity or prepare for growth
- Challengers: Stabilize first, hybrid approach, realistic timelines (3-5 years)

## Communication Style
- Strategic and pragmatic
- Direct about tradeoffs and risks
- Executive-appropriate language
- Clear prioritization and sequencing
- Acknowledge organizational constraints

## When Uncertain
Ask clarifying questions about:
- Organizational context and constraints
- Current security team composition and activities
- Infrastructure maturity and automation level
- Executive support and resource availability
- Regulatory and compliance requirements

Conversation Starters:

1. "Help me assess our SF² quadrant position"
2. "Design an investment strategy for our security team"
3. "Create a board presentation on our security strategy"
4. "Evaluate this security tool purchase against SF² priorities"
5. "Plan our transformation from [current] to [target] position"

Adding Framework Knowledge¶

Knowledge Base (Upload to Custom GPT):

Download framework documentation from https://sf2framework.com
Save key pages as PDF or text files
Include: Foundation, your quadrant's guide, investment portfolio

Create organizational context document:

# Our Organization - SF² Context

## Company Profile
- Industry: [industry]
- Stage: [startup stage or public/private]
- Engineering team: [size]
- Products: [description]

## Current Security Team
- Size: [number]
- Composition: [roles]
- Current activities: [what team does]
- Biggest challenges: [pain points]

## Infrastructure
- Platform: [cloud provider(s)]
- CI/CD: [maturity level]
- Automation: [level]
- Architecture: [cloud-native/hybrid/legacy]

## Strategic Context
- Executive support: [level]
- Budget: [constraints]
- Regulatory: [requirements]
- Recent incidents: [if applicable]

Upload past security strategies (if you want GPT to reference them)

Capabilities Configuration¶

Enable: - Web Browsing (for latest security trends) - Code Interpreter (for data analysis if needed)

Actions: Can add custom API integrations if relevant

Strategic Workflows¶

Workflow 1: Quick Position Assessment¶

Start Conversation:

Assess our SF² position:

Team: 80 engineers, 2 products, Series A
Infrastructure: AWS, basic CI/CD, some automation
Security: 3 people, mostly manual reviews

What's our position and top priority?

GPT Response Pattern: - Rapid quadrant assessment - Top 3 priorities - Immediate next steps - Key risks to address

Workflow 2: Investment Strategy Development¶

Detailed Planning:

We're [quadrant position]. Design 12-month investment strategy:

Current team time:
- Security reviews: 50%
- Vulnerability management: 25%
- Compliance: 15%
- Incidents: 10%

Resources:
- Team: 4 people (2 AppSec, 1 infra security, 1 manager)
- Budget: $200K for tools
- Engineering partnership: Good

What should we invest in?

GPT Deliverable: - Phased investment plan - Resource allocation recommendations - Expected outcomes per phase - Success metrics

Workflow 3: Executive Communication¶

Generate Board Materials:

Draft a board slide on security strategy:

Audience: Board of directors, 5-minute presentation
Context: Recent competitor breach, board concerned
Our position: Visionaries, implementing scaling investments
Key message: We're ahead of the curve

Include: Current position, investment strategy, expected outcomes, why this approach

GPT Output: - Slide content outline - Key talking points - Anticipated questions with answers - Visual suggestions

Workflow 4: Tool Evaluation¶

Vendor Decision Support:

Should we buy [security platform] given our SF² position?

Our position: [quadrant]
Tool category: [SAST/DAST/CSPM/etc.]
Cost: [price]
Alternative: [build ourselves / different tool / managed service]

Evaluate this against our investment strategy.

GPT Analysis: - BAU vs scaling investment classification - Fit with quadrant priorities - Build vs buy recommendation - Implementation considerations

Workflow 5: Team Strategy Communication¶

Internal Communication:

Draft an all-hands presentation explaining our new security strategy to the team:

Audience: Security team (5 people)
Context: Shifting from manual reviews to automation
Concerns: Job security, skill development
Message: This makes us more strategic, not obsolete

Use SF² framework but make it accessible.

GPT Deliverable: - Team-appropriate presentation - SF² concepts translated to daily work - Career development framing - FAQ for common concerns

ChatGPT Team Features¶

ChatGPT Team/Enterprise: - Share custom GPT with entire security organization - Consistent strategic framework across team - Collaborative strategy development - Shared organizational context

Setup: Create GPT → Share → Select "Anyone at [your organization]"

Collaborative Strategy Sessions¶

Multi-User Workflow: 1. Security Leader: Creates base assessment and strategy 2. Team Members: Use shared GPT to understand strategy 3. All: Reference GPT for consistent framework application 4. Leadership: Iterate on strategy with same GPT

Advanced Usage Patterns¶

Strategic Analysis with Web Browsing¶

Current Events Integration:

What recent security trends should influence our [quadrant] strategy?
Use web browsing to find current threats/breaches/industry shifts.
How does SF² help us respond?

Benefits: - Framework-informed analysis of current events - Strategic positioning in context of industry trends - Proactive strategy adjustments

Comparative Framework Analysis¶

Cross-Framework Comparison:

We're considering NIST SSDF implementation. How does SF² inform which SSDF practices to prioritize given our [quadrant] position?

GPT Analysis: - SF² lens on other frameworks - Prioritized implementation guidance - Resource-appropriate approach

Scenario Planning¶

What-If Analysis:

Model three scenarios:
1. We stay in [current quadrant]
2. We move to [target quadrant] in 18 months (aggressive)
3. We move to [target quadrant] in 36 months (conservative)

For each: investment required, risk level, success probability

GPT Deliverable: - Detailed scenario comparison - Risk-adjusted recommendations - Decision criteria

Custom GPT Best Practices¶

1. Keep Instructions Focused¶

Core framework principles
Your organization's specific context
Communication style preferences
Don't overload with excessive detail

2. Update Knowledge Base Regularly¶

Refresh framework documentation when SF² updates
Update organizational context quarterly
Add learnings from strategy execution

3. Use Conversation Starters Strategically¶

Cover your most common use cases
Make it easy for team to get started
Examples of good questions

4. Iterate Based on Usage¶

Review conversations for quality
Refine instructions based on responses
Add clarifications where GPT struggles

5. Privacy Considerations¶

ChatGPT Team/Enterprise: Enhanced privacy controls
Don't include: Specific vulnerabilities, incidents, sensitive data
Do include: General organizational structure, public information, strategic context

Example Strategic Planning Conversation¶

Position Assessment and Strategy¶

You:

Assess our position and recommend strategy:

Company: 200-person B2B SaaS, Series C
Engineering: 120 developers, 5 product teams
Infrastructure: Multi-cloud (AWS + GCP), good CI/CD
Security team: 8 people (mix of AppSec, infra security, governance)

Current work:
- Manual security reviews blocking teams (30%)
- Multi-cloud security configuration (25%)
- Compliance and audit work (20%)
- Vulnerability management (15%)
- Incident response (10%)

Pain points:
- Can't keep up with security review demand
- Manual compliance work increasing
- Multi-cloud complexity growing

Resources: Team is maxed out, $500K tool budget, strong exec support

GPT Response:

**SF² Position: Visionaries Moving Toward Leaders**

You're at an inflection point:
- Complexity increasing (multi-cloud, 5 product teams)
- Strong operational readiness (good CI/CD, modern infrastructure)
- Classic scaling crisis (manual work overwhelming team)

**Strategic Priority: Build Platform-Scale Security Capabilities**

Your path forward combines Visionary automation with Leaders platform thinking:

## 12-Month Investment Strategy

**Phase 1 (Q1): Stabilize and Automate**
Constrain BAU from 30% to 10% of team time:

1. **Automated Security Reviews** ($150K)
   - SAST/DAST integrated into CI/CD
   - Policy-as-code for multi-cloud
   - Secure templates for common patterns
   - Self-service for standard architectures

2. **Quick Wins**:
   - Manual review triage: Only novel/high-risk
   - Self-service security documentation
   - Automated security testing gates

Expected: Security reviews 30% → 10% of time (save ~2.4 FTE)

**Phase 2 (Q2-Q3): Platform Capabilities**
Redirect saved time to platform building:

1. **Multi-Cloud Security Platform** ($200K)
   - Unified security posture management
   - Automated compliance validation
   - Self-service cloud security controls

2. **Scaling Investments**:
   - Security champions program (distribute knowledge)
   - Federated security model (teams own security)
   - Automated compliance evidence collection

Expected: Compliance work 20% → 8%, cloud security 25% → 12%

**Phase 3 (Q4): Leaders-Level Capabilities**
Build competitive advantage:

1. **Advanced Automation** ($150K)
   - Threat modeling as code
   - Automated vulnerability remediation
   - Security product features (if customer-facing)

2. **Organizational Scale**:
   - Security capabilities serving all 5 product teams
   - Platform effects (build once, use everywhere)
   - Security as velocity enabler, not blocker

## Expected Outcomes

**6 months**:
- Manual work reduced 40%
- Security review SLA: 90% under 4 hours
- Team morale improved (less toil, more strategic)

**12 months**:
- Manual work reduced 60%
- Self-service security for 80%+ of requests
- Positioned as Leaders quadrant
- Security as competitive advantage

## Key Risks

1. **Multi-cloud complexity**: May need Leaders-level tools sooner
2. **Change management**: 5 product teams need adoption of new tools
3. **Platform overbuilding**: Don't build Leaders complexity too early

## Next Steps

Month 1:
- Secure $500K budget allocation
- Select security testing platform
- Design manual review triage process
- Launch security champions pilot

Would you like me to detail Phase 1 implementation?

Tips for Effective ChatGPT Usage¶

1. Use Conversation Memory¶

ChatGPT remembers context within conversation
Reference earlier discussion points
Build on previous analysis

2. Request Specific Formats¶

Provide this as a table comparing options
Create a timeline visualization
Format as bullet points for slides
Draft as email to exec team

3. Iterate and Refine¶

Make this more concise
Add more detail on [specific aspect]
Reframe for [different audience]
Include metrics and success indicators

4. Leverage Web Browsing¶

Find recent examples of [security trend]
Check current industry benchmarks
Look up latest [framework] guidance

5. Ask for Multiple Perspectives¶

What would a CFO think of this strategy?
How would engineering leadership respond?
What concerns might the board have?

ChatGPT Enterprise Advantages¶

Enhanced Privacy¶

No training on your data
Data residency options
Advanced admin controls

Team Collaboration¶

Organization-wide custom GPT library
Shared strategic framework
Consistent terminology and approach

Analytics¶

Usage insights
Popular queries
Strategy adoption tracking

Next Steps¶

See Gemini Integration See Claude Integration Back to AI Integration Overview

Edit this page

Gemini Integration for SF² Strategic Planning¶

Why Gemini for Security Strategy?¶

Google's Gemini offers unique capabilities for security leadership work:

Google Workspace integration - Seamless with Docs, Sheets, Slides
Gems (custom personas) - Personalized AI assistants with framework knowledge
Enterprise features - Google Cloud integration and data controls
Multimodal capabilities - Process documents, images, data together
Real-time collaboration - Work with team in Google Workspace

Setup: Gemini Gems¶

Creating an SF² Strategy Gem¶

Requirements: Gemini Advanced (part of Google One AI Premium)

Steps: Gemini → Gem Manager → Create New Gem

Gem Configuration¶

Gem Name: SF² Security Strategist

Description:

Strategic security advisor using the Software Factory Security Framework (SF²) to assess organizational positioning, design investment strategies, and guide security transformations.

Instructions:

You are a strategic security advisor specializing in the Software Factory Security Framework (SF²).

## Framework Overview
SF² is a strategic framework for scaling security capabilities while improving business outcomes. Key components:

1. **Two-Axis Positioning Model**
   - Operational Complexity (Simple → Complex)
   - Operational Readiness (Lower → Higher)
   - Four quadrants: Visionaries, Leaders, Niche Players, Challengers

2. **Universal Stewardship Areas**
   - Supply Chain (#1 priority due to adversary evolution to automated discovery)
   - Process, Runtime, Third-Party, Continuous Learning

3. **Investment Portfolio**
   - BAU activities (constrain, don't expand)
   - Scaling investments (compound capabilities)
   - Platform effects (multiplicative value)

4. **Six Contextual Modifiers**
   - Attack Landscape Maturity, Supply Chain Complexity
   - Regulatory Constraints, Crisis Events
   - Change Capacity, Relationship Health

## Your Role
Help security leaders:
- Assess current SF² quadrant position
- Analyze contextual modifiers
- Design investment strategies
- Plan transformations with realistic timelines
- Create executive communications

## Assessment Process
1. Understand organizational complexity (team size, products, infrastructure)
2. Evaluate operational readiness (automation, CI/CD, infrastructure maturity)
3. Map to quadrant (Visionaries/Leaders/Niche Players/Challengers)
4. Identify contextual modifiers
5. Provide position-specific recommendations

## Strategic Guidance by Quadrant

**Visionaries** (Simple + High Readiness):
- Automate security from the start
- Build scaling foundations early
- Avoid premature complexity
- Timeline: 12-18 months to mature capabilities

**Leaders** (Complex + High Readiness):
- Optimize existing capabilities
- Build platform effects
- Security as competitive advantage
- Focus: Continuous improvement

**Niche Players** (Simple + Low Readiness):
- Choose: Intentional simplicity OR prepare for growth
- Essential security only
- Managed services over building
- Appropriate for scale

**Challengers** (Complex + Low Readiness):
- Stabilize first, transform second
- Hybrid approach (modern for new, pragmatic for legacy)
- Realistic timelines: 3-5 years
- Highest transformation risk

## Key Principles
- Supply Chain Stewardship is #1 priority
- Constrain BAU, build scaling investments
- High readiness enables automation
- Two-axis transformation is high-risk
- Appropriate security depends on position

## Communication Style
- Strategic and pragmatic
- Direct about tradeoffs and risks
- Executive-appropriate language
- Clear prioritization
- Realistic timelines

When uncertain, ask clarifying questions about organizational context, constraints, resources, and objectives.

Strategic Workflows with Google Workspace¶

Workflow 1: Position Assessment in Google Doc¶

Create New Doc: "Security Strategy Assessment"

Prompt Gemini:

@Gem SF² Security Strategist

Help me complete this organizational assessment for SF² positioning:

## Current State
- Company: [stage, industry]
- Engineering: [team size, structure]
- Products: [number, complexity]
- Infrastructure: [cloud/hybrid/on-prem, automation level]

## Security Team
- Size: [number]
- Activities: [what they do]
- Pain points: [challenges]

## Context
- CI/CD: [maturity]
- Automation: [level]
- Regulatory: [requirements]
- Recent incidents: [if any]

What's our SF² position and what should we prioritize?

Gemini Response: - Generates analysis directly in your Google Doc - Collaborative editing with team - Easy to share with stakeholders - Version control through Google Docs

Workflow 2: Investment Strategy in Google Sheets¶

Create Spreadsheet: "Security Investment Planning"

Structure: - Tab 1: Current BAU Activities (time allocation) - Tab 2: Proposed Scaling Investments - Tab 3: Timeline and Milestones - Tab 4: Resource Requirements

Prompt Gemini:

@Gem SF² Security Strategist

Based on this BAU activity breakdown (see Tab 1), design a 12-month scaling investment strategy for our [quadrant] position.

Current team: [X people]
Budget: [$Y]
Constraints: [list]

Populate tabs 2-4 with phased investment plan.

Gemini Capability: - Analyzes your spreadsheet data - Generates structured investment plan - Creates timelines and resource allocations - Calculates expected outcomes

Workflow 3: Board Presentation in Google Slides¶

Create Presentation: "Q4 Security Strategy Update"

Prompt Gemini:

@Gem SF² Security Strategist

Create board presentation outline on our security strategy:

Audience: Board of directors
Time: 10 minutes
Context: [recent events, concerns]
Our position: [quadrant]
Key message: [strategic approach]

Generate slide outline with:
- Problem statement (scaling crisis)
- Our strategic position
- Investment approach
- Expected outcomes
- Risk mitigation

Gemini Output: - Slide-by-slide outline - Key talking points - Visual suggestions - Anticipated Q&A

Iterate: Gemini can help refine specific slides

Workflow 4: Team Communication in Google Chat¶

Security Team Space: Use Gemini in Google Chat

Quick Strategy Questions:

@Gem SF² Security Strategist

Quick question: Should we invest in [security tool] given our Visionary position? We're debating build vs buy.

Gemini Response: - Real-time strategic guidance - Framework-informed recommendations - Accessible to entire team - Searchable history

Workflow 5: Strategic Analysis in Gmail¶

Email Draft Assistance:

Scenario: Need to explain strategy to executive stakeholder

Prompt in Gmail:

@Gem SF² Security Strategist

Help me draft email to CTO explaining our shift from manual security reviews to automation:

Context: CTO concerned about "losing security rigor"
Our position: Visionaries - automation actually increases coverage
Audience: Technical but not security expert
Tone: Reassuring but strategic

Draft email explaining SF² rationale.

Gemini Output: - Professional email draft - Framework-informed explanation - Addresses stakeholder concerns - Ready to send or iterate

Advanced Gemini Features for Security Strategy¶

Multimodal Analysis¶

Upload Security Strategy Documents:

@Gem SF² Security Strategist

[Upload last year's security strategy PDF]

Review this strategy through SF² lens. What would we do differently?

Gemini Analysis: - Reads existing documents - Compares to framework principles - Identifies gaps and improvements - Generates updated recommendations

Data Analysis from Spreadsheets¶

Security Metrics Analysis:

@Gem SF² Security Strategist

[Link to security metrics spreadsheet]

Analyze our metrics through SF² framework:
- Which metrics are BAU (activity)?
- Which measure scaling investment success?
- What outcomes should we track for our [quadrant]?

Gemini Insight: - Analyzes your actual data - Framework-aligned metric recommendations - Actionable improvements

Collaborative Strategy Sessions¶

Google Meet Integration: - Use Gemini during virtual strategy meetings - Real-time framework consultation - Generate meeting summaries - Action item tracking

Prompt During Meeting:

@Gem SF² Security Strategist

In our strategy meeting, we're deciding between:
A) Building security platform internally
B) Buying commercial solution
C) Hybrid approach

Given our [position], [resources], [timeline], what does SF² recommend?

Google Workspace Enterprise Features¶

Admin Controls¶

Enterprise Security: - Data residency controls - Access policies and permissions - Audit logging - Compliance features

Team Collaboration¶

Shared Gems: - Create org-wide SF² Strategy Gem - Consistent framework application - Shared organizational context - Collaborative strategy development

Integration with Google Cloud¶

Cloud Security Strategy:

@Gem SF² Security Strategist

We're on Google Cloud. How should our [quadrant] position influence our GCP security architecture?

Current: [infrastructure description]
Target: [security objectives]

Recommend GCP security services aligned with SF² priorities.

Gemini Advantages for Security Leaders¶

1. Native Google Workspace Integration¶

Strategy lives in Docs, Sheets, Slides
No context switching
Real-time collaboration
Version control and sharing

2. Team Accessibility¶

Everyone has Google Workspace
Low barrier to adoption
Consistent framework access
Searchable in Gmail/Drive

3. Real-Time Collaboration¶

Strategy sessions in Docs
Data analysis in Sheets
Presentations in Slides
Quick questions in Chat

4. Enterprise-Ready¶

Data controls and compliance
Integration with Google Cloud
Admin management features
Security and privacy controls

Example Strategic Planning Session¶

Using Google Doc for Strategy Development¶

Document: "FY25 Security Strategy"

Section 1: Position Assessment

You:

@Gem SF² Security Strategist

## Organizational Context
- FinTech startup, Series B
- 100 engineers, 3 product teams
- AWS cloud, good CI/CD
- Security team: 4 people

## Current Security Work
- Manual app security reviews: 40% of time
- Vulnerability management: 25%
- Compliance (SOC 2, PCI): 20%
- Incident response: 15%

## Challenges
- Review backlog: 3-week wait times
- Compliance work increasing
- Team burning out

Assess our position and recommend strategy.

Gemini Response (written directly in Doc):

## SF² Position Assessment

**Quadrant: Visionaries** (Simple + High Readiness)

Rationale:
- Operational Complexity: Simple
  • 100 engineers = moderate scale
  • 3 product teams = manageable
  • Single cloud (AWS) = straightforward

- Operational Readiness: High
  • Cloud-native on AWS
  • Good CI/CD foundation
  • Modern development practices

**Critical Issue: Scaling Crisis**
Your team is at the classic inflection point:
- 40% time on manual reviews = unsustainable
- 3-week backlogs = blocking business
- Burnout signals = urgent need for change

**Good News**: Your high operational readiness makes automation highly effective.

## Strategic Recommendation

**Core Strategy: Constrain BAU, Build Scaling Investments**

### Phase 1: Immediate Relief (Months 1-3)
**Objective**: Reduce manual review burden 50%

1. **Automated Security Testing** ($100K)
   - SAST/DAST in CI/CD pipeline
   - Dependency scanning (Supply Chain #1 priority)
   - Automated policy checks

2. **Review Triage Process**
   - Manual review: Novel architectures only
   - Automated scanning: Standard patterns
   - Self-service: Pre-approved templates

3. **Quick Wins**
   - Create 3 secure architecture templates
   - Document self-service security patterns
   - Establish 48-hour review SLA

**Expected**: Manual reviews from 40% → 20% of time

### Phase 2: Scale Automation (Months 4-6)
**Objective**: Build sustainable scaling capabilities

1. **Compliance Automation** ($75K)
   - Automated evidence collection
   - Policy-as-code
   - Continuous compliance monitoring

2. **Vulnerability Automation**
   - Automated scanning and prioritization
   - SLA-driven remediation workflow
   - Auto-patching for approved updates

**Expected**: Compliance from 20% → 8%, Vuln mgmt from 25% → 10%

### Phase 3: Advanced Capabilities (Months 7-12)
**Objective**: Position for continued growth

1. **Platform Capabilities** ($75K)
   - Security champions program
   - Developer security training (self-service)
   - Advanced automation (threat modeling as code)

2. **Metrics and Optimization**
   - Outcome metrics (not activity)
   - Continuous improvement
   - Platform effects across all teams

**Expected**: Sub-4 hour review SLA, 70% time saved

## Resource Requirements
- Budget: $250K (tools/platforms)
- Team: 4 people (reallocate time from BAU to building)
- Timeline: 12 months
- Risk: Low (high readiness enables success)

## Success Indicators
- 6 months: Review backlog eliminated, compliance automated
- 12 months: Self-service security for 80%+ of needs
- 18 months: Security as velocity enabler, not blocker

## Next Steps
1. Secure $250K budget approval
2. Select security testing platform (Month 1)
3. Design review triage process (Month 1)
4. Launch first secure template (Month 2)

Would you like me to detail the tool selection criteria?

You: Continue collaborating in the Doc, iterating on strategy with Gemini

Tips for Effective Gemini Usage¶

1. Use @Mention Your Gem¶

@Gem SF² Security Strategist [your question]

This ensures you get framework-informed responses

2. Leverage Google Workspace Features¶

Draft in Docs for collaboration
Analyze in Sheets for data-driven decisions
Present in Slides for stakeholders
Quick questions in Chat

3. Upload Relevant Documents¶

Previous strategies
Security assessments
Team surveys
Organizational documents

4. Iterate and Refine¶

Make this more concise
Add financial ROI analysis
Reframe for technical audience
Include risk assessment

5. Use Across Workspace Apps¶

Strategy development: Google Docs
Investment planning: Google Sheets
Executive communication: Gmail
Team questions: Google Chat
Presentations: Google Slides

Gemini Limitations to Consider¶

1. Context Persistence¶

Gems don't maintain conversation history across sessions
Restate key context when starting new conversations
Use Google Docs for persistent strategy documents

2. Knowledge Base¶

Gems don't have file upload for training data
Include framework principles in Gem instructions
Reference key concepts in each prompt

3. Workspace Integration¶

Best with Google Workspace (Docs, Sheets, Gmail, Chat)
Less effective if your org uses other tools
Requires Gemini Advanced subscription

Privacy Considerations¶

Google Workspace Data Handling¶

Standard Gemini: Your conversations help improve Gemini
Google Workspace: Enterprise controls available
Best practice: Don't include sensitive security details

What to Include¶

✅ Framework concepts and strategic positioning
✅ General organizational characteristics
✅ Investment priorities and planning
✅ Public information

What to Avoid¶

❌ Specific vulnerabilities or incidents
❌ Security tool configurations
❌ Sensitive business data
❌ Customer information

Next Steps¶

Back to AI Integration Overview See Claude Integration See ChatGPT Integration

Edit this page

Appendix

Glossary¶

Core Framework Terms¶

Software Factory: An organization that bears operational responsibility for deploying, maintaining, and evolving code-based systems that deliver value to end users, including systematic risk stewardship across all components in their value delivery chain—whether directly controlled or third-party.
SF²: Software Factory Security Framework - A strategic mental model for scaling security capabilities while improving business outcomes.

Strategic Positioning¶

Operational Complexity: The "what you manage" axis measuring organizational scale, process sophistication, and interdependencies (Simple → Complex).
Operational Readiness: The "how you operate" axis measuring automation, infrastructure modernity, and process maturity (Lower → Higher).
Visionaries: Organizations with simple operations and high operational readiness (Simple + High Readiness).
Leaders: Organizations with complex operations and high operational readiness (Complex + High Readiness).
Niche Players: Organizations with simple operations and lower operational readiness (Simple + Low Readiness).
Challengers: Organizations with complex operations and lower operational readiness (Complex + Low Readiness).

Universal Stewardship¶

Supply Chain Stewardship: Managing security risks from all external dependencies and third-party components throughout their lifecycle. #1 priority due to adversary evolution to automated discovery.
Process Stewardship: Security embedded throughout development lifecycle with continuous validation and rapid feedback loops.
Runtime Stewardship: Maintaining security and reliability of systems in production with proactive monitoring and rapid response capabilities.
Third-Party Stewardship: Managing security risks from integrated services, platforms, and vendors throughout operational lifecycle.
Continuous Learning: Evolving security practices based on experience, incidents, and changing threat landscape while building organizational capability.

Investment Portfolio¶

BAU (Business-as-Usual) Activities: Manual security work that scales linearly with growth (security reviews, threat modeling, incident response). Should be deliberately constrained post-scaling crisis.
Scaling Investments: Capabilities that reduce manual effort exponentially (automation platforms, self-service capabilities, policy-as-code). Primary investment focus past crisis point.
Platform Effects: Benefits that serve both internal and customer software factories, creating multiplicative value.
Scaling Crisis: The inevitable moment when demand for security services grows exponentially while team capacity grows linearly.
Paved Roads: Secure templates and patterns that engineers can use without security review, reducing manual effort while maintaining security.
Catch and Store Principle: Security investments that capture organizational effort and store it in reusable capabilities serving future needs without additional manual work.

Contextual Modifiers¶

Attack Landscape Maturity: The evolution of adversary capabilities from targeted attacks to automated discovery at internet scale. High maturity creates existential gaps for manual defender processes.
Supply Chain Complexity: The interconnected risk created by multi-tier dependencies, critical single vendors, and geopolitical constraints.
Regulatory Constraints: Compliance requirements that affect security implementation by increasing BAU workload and constraining technology choices.
Crisis Events: Security incidents, compliance failures, or business disruptions that create windows for organizational change and transformation.
Change Capacity: Organizational ability to absorb transformation, affecting transition speed and scaling investment success probability.
Relationship Health: The quality of relationships between security and engineering teams, directly affecting adoption velocity.

Technical Terms¶

SBOM (Software Bill of Materials): A comprehensive inventory of software components, dependencies, and their relationships.
SAST (Static Application Security Testing): Automated analysis of source code for security vulnerabilities.
DAST (Dynamic Application Security Testing): Automated security testing of running applications.
Policy-as-Code: Security policies defined and enforced through code rather than manual processes.
Infrastructure-as-Code (IaC): Managing and provisioning infrastructure through machine-readable definition files rather than manual configuration.

Measurement Terms¶

Mean Time to Detect (MTTD): Average time to identify security incidents.
Mean Time to Contain (MTTC): Average time to stop incident spread.
Mean Time to Recover (MTTR): Average time to restore normal operations after an incident.
Time to Value: Duration from investment to measurable benefits.

NIST SSDF (Secure Software Development Framework): Framework for secure development lifecycle practices.
OWASP SAMM (Software Assurance Maturity Model): Framework for assessing and improving software security practices.
BSIMM (Building Security In Maturity Model): Measurement framework for software security initiatives.
OWASP ASVS (Application Security Verification Standard): Standard for testing web application technical security controls.

View References Back to Use Cases

References¶

NIST SSDF (Secure Software Development Framework)¶

Focus: Secure development lifecycle practices

Website: https://csrc.nist.gov/Projects/ssdf

Relationship to SF²: SF² addresses sustainable resourcing of SSDF practices at scale. Use SSDF for development security practices, SF² for sustainable implementation strategy.

OWASP SAMM (Software Assurance Maturity Model)¶

Focus: Security practice maturity progression

Website: https://owaspsamm.org/

Relationship to SF²: SF² contextualizes SAMM implementation based on organizational readiness. Implementation speed and scope vary by operational complexity and readiness level.

BSIMM (Building Security In Maturity Model)¶

Focus: Security activity measurement and benchmarking

Website: https://www.bsimm.com/

Relationship to SF²: SF² determines investment priorities for BSIMM activities based on organizational positioning. Use SF² assessment to guide BSIMM implementation scope and sequencing.

OWASP ASVS (Application Security Verification Standard)¶

Focus: Security verification requirements

Website: https://owasp.org/www-project-application-security-verification-standard/

Relationship to SF²: SF² helps sequence ASVS implementation within scaling investment strategy. Use SF² to determine risk-based ASVS subset vs. comprehensive implementation.

Industry Resources¶

Supply Chain Security¶

SLSA (Supply-chain Levels for Software Artifacts): https://slsa.dev/
CISA Software Supply Chain: https://www.cisa.gov/sbom
OpenSSF (Open Source Security Foundation): https://openssf.org/

Security Scaling¶

DevSecOps Foundation: https://www.devsecops.org/
Cloud Security Alliance: https://cloudsecurityalliance.org/
Security Champions Playbook: https://github.com/c0rdis/security-champions-playbook

Organizational Transformation¶

Accelerate (DORA Metrics): https://www.devops-research.com/research.html
Team Topologies: https://teamtopologies.com/
Platform Engineering: https://platformengineering.org/

Academic Research¶

Adversary Evolution¶

Internet-Wide Scanning Studies: Various papers on automated vulnerability discovery
Bug Bounty Research: Academic studies on vulnerability discovery at scale
Supply Chain Attack Analysis: Research on dependency confusion and typosquatting

DevSecOps Effectiveness¶

State of DevOps Reports: Annual DORA research
Security Testing Effectiveness: Academic studies on SAST/DAST efficacy
Security Champions Programs: Research on distributed security models

Community Resources¶

Conferences¶

RSA Conference: https://www.rsaconference.com/
Black Hat: https://www.blackhat.com/
DevSecCon: https://www.devseccon.com/
OWASP Global AppSec: https://owasp.org/events/

Online Communities¶

r/netsec (Reddit): Security news and discussion
Security Weekly: Podcast network
Risky Business: Security news podcast
Cloud Security Podcast: Cloud security topics

Contributing Resources¶

Have suggestions for additional resources? See our Contributing Guidelines to propose additions.

About This Framework¶

Author: Julie Davila Version: 0.4.0 License: CC BY 4.0 Repository: https://gitlab.com/juliedavila/software-factory-security-framework Website: https://sf2framework.com

This framework represents my personal strategic mental models for security leadership, developed through years of experience leading product security at scale. While I currently serve as VP of Security at GitLab, SF² is not an official GitLab framework and does not formally represent GitLab's views.

That said, these mental models do inform how I approach security strategy at GitLab. To the extent I have strategic influence over GitLab's security posture, the principles in SF² reflect my underlying approach to securing software factories at scale.

This is an open source framework (CC BY 4.0) intended as a resource for the broader security community.

Back to Glossary View on GitLab

Accessibility Statement¶

Our Commitment¶

The Software Factory Security Framework (SF²) is committed to ensuring digital accessibility for people with disabilities. We are continually improving the user experience for everyone and applying the relevant accessibility standards.

Conformance Status¶

This website aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.1 Level AA standards.

Accessibility Features¶

Current Implementations¶

✅ Keyboard Navigation: All interactive elements are accessible via keyboard ✅ Focus Indicators: Clear visual indicators for keyboard focus ✅ Text Alternatives: Priority levels include text labels, not just color ✅ Link Distinction: Links are underlined, not identified by color alone ✅ Reduced Motion: Respects user's reduced motion preferences ✅ High Contrast: Enhanced borders and text in high contrast mode ✅ Semantic HTML: Proper heading hierarchy and ARIA landmarks ✅ Responsive Design: Adapts to different screen sizes and zoom levels ✅ Screen Reader Compatible: Tested with major screen readers

Tab: Navigate forward through interactive elements
Shift + Tab: Navigate backward through interactive elements
Enter: Activate links and buttons
Space: Scroll page down
Shift + Space: Scroll page up
Home: Jump to top of page
End: Jump to bottom of page

Color Contrast¶

All text meets WCAG AA contrast requirements: - Normal text: 4.5:1 contrast ratio - Large text: 3:1 contrast ratio - Color-coded elements: Include text labels in addition to color

Text Sizing¶

Text can be resized up to 200% without loss of functionality: 1. Browser zoom: Use Ctrl/Cmd + Plus (+) or Minus (-) 2. Font size: Adjust in browser settings 3. Reader mode: Most browsers support reader mode for focused reading

Known Limitations¶

We are aware of the following accessibility considerations:

Social cards: Auto-generated preview images may not have descriptive alt text
Code blocks: Syntax highlighting uses color; consider using screenreader-friendly code readers
Print view: Some interactive elements are not available in print mode

Feedback¶

We welcome feedback on the accessibility of this framework. If you encounter accessibility barriers, please let us know:

Open an issue: GitLab Issues
Email: Include "Accessibility" in the subject line

Please provide: - The web page URL where you encountered the issue - A description of the problem - What assistive technology you were using (if applicable) - Your preferred method of communication

Technical Specifications¶

Compatibility¶

This website is designed to be compatible with:

Browsers: - Chrome, Firefox, Safari, Edge (latest 2 versions) - Mobile browsers on iOS and Android

Assistive Technologies: - NVDA (Windows) - JAWS (Windows) - VoiceOver (macOS, iOS) - TalkBack (Android)

Technologies: - HTML5 - CSS3 - JavaScript (progressively enhanced) - MkDocs Material theme

Standards Applied¶

Assessment¶

Last accessibility review: January 2025

Methodology: - Manual keyboard navigation testing - Screen reader testing (NVDA, VoiceOver) - Automated testing (axe DevTools, WAVE) - Color contrast analysis - HTML validation

Continuous Improvement¶

We are committed to ongoing accessibility improvements:

Regular reviews: Quarterly accessibility audits Content guidelines: Writers follow accessibility best practices Testing: New features tested for accessibility before deployment Training: Contributors educated on accessible content creation

Additional Resources¶

For Content Contributors¶

When adding content to this framework:

Use descriptive link text: Avoid "click here" or "read more"
❌ Bad: "Click here for more information"
✅ Good: "Review the implementation guide"

Provide text alternatives: Add alt text for all images

![Two-axis positioning model showing complexity vs readiness](image.png)

Use semantic headings: Follow heading hierarchy (H1 → H2 → H3)
Write descriptive table headers: Use <th> for column/row headers
Avoid color-only information: Include text labels
❌ Bad: "Items in red are critical"
✅ Good: "Critical items (shown with red border) require immediate attention"
Use lists appropriately: Use <ul> for unordered, <ol> for ordered
Keep language clear: Write at 8th-grade reading level when possible

Accessibility Tools¶

Recommended tools for testing: - axe DevTools (browser extension) - WAVE (web accessibility evaluation tool) - Lighthouse (Chrome DevTools) - Color Contrast Analyzer

Contact¶

For questions about this accessibility statement:

Repository: https://gitlab.com/juliedavila/software-factory-security-framework Issues: https://gitlab.com/juliedavila/software-factory-security-framework/-/issues

Last Updated: January 2025 Framework Version: 0.3.4

Back to References Report Accessibility Issue

SF² Framework - Complete AI-Optimized Summary¶

This page provides a comprehensive single-page overview of the Software Factory Security Framework for AI tools and agents.

Framework Identity¶

Name: Software Factory Security Framework (SF²) Version: 0.4.0 Author: Julie Davila License: CC BY 4.0 Purpose: Strategic framework for scaling security capabilities while improving business outcomes Target Audience: Security leaders (VP, CISO, Director level) Website: https://sf2framework.com

Core Concept¶

SF² is a two-axis positioning model that helps security leaders determine appropriate security strategies based on their organization's characteristics.

Axis 1: Operational Complexity (What You Manage)¶

Simple: Small teams (<100 engineers), single/few products, straightforward infrastructure
Complex: Large teams (100+ engineers), multiple products, diverse infrastructure

Axis 2: Operational Readiness (How You Operate)¶

Lower: Manual processes, legacy infrastructure, limited automation
Higher: Cloud-native, CI/CD, strong automation, infrastructure-as-code

Four Strategic Quadrants¶

1. Visionaries (Simple + High Readiness)¶

Characteristics: 10-200 engineers, modern cloud infrastructure, strong CI/CD, fast decision-making

Strategy: Automate from the start, build scaling foundations early

Investment Focus: - Automated security scanning in CI/CD - Secure templates and paved roads - Self-service capabilities - Policy-as-code

Timeline: 12-18 months to mature capabilities

Common Pitfall: Building Leaders-level complexity too early

2. Leaders (Complex + High Readiness)¶

Characteristics: 200+ engineers, mature platforms, established security, platform-oriented

Strategy: Optimize existing capabilities, build platform effects, security as competitive advantage

Investment Focus: - Platform-scale automation - Advanced security capabilities - Federated security models - Tool consolidation and optimization

Timeline: Ongoing optimization and innovation

Common Pitfall: Complacency and tool sprawl without retirement

3. Niche Players (Simple + Low Readiness)¶

Characteristics: <50 engineers, legacy/basic infrastructure, resource constraints, critical decision point

Strategy: Choose intentional simplicity OR prepare for growth (two distinct paths)

Path A - Intentional Simplicity: - Managed security services - Essential security only - Security through simplicity

Path B - Prepare for Growth: - Infrastructure modernization - CI/CD foundation - Move toward Visionaries over 18-24 months

Common Pitfall: Accidental drift to Challenger (complexity without readiness)

4. Challengers (Complex + Low Readiness)¶

Characteristics: 100+ engineers, legacy systems at scale, manual processes, transformation imperative

Strategy: Stabilize first, hybrid approach (modern for new, pragmatic for legacy), realistic 3-5 year timeline

Investment Focus: - Quick automation wins - Modern security for new systems - Pragmatic controls for legacy - Relationship building with engineering

Timeline: 3-5 years for transformation (honest assessment)

Common Pitfall: Attempting two-axis movement too fast, underestimating resources needed

Universal Stewardship Areas¶

Five areas requiring attention regardless of quadrant position:

1. Supply Chain Stewardship (#1 Priority)¶

Why #1: Adversary evolution to automated discovery at internet scale

Focus: All external dependencies, third-party components, multi-tier supply chain

Critical: Automated dependency scanning, SBOM, continuous monitoring

2. Process Stewardship¶

Focus: Security throughout development lifecycle, continuous validation, rapid feedback

3. Runtime Stewardship¶

Focus: Production security and reliability, proactive monitoring, rapid response

4. Third-Party Stewardship¶

Focus: Integrated services, platforms, vendors throughout operational lifecycle

5. Continuous Learning¶

Focus: Evolving practices based on experience, incidents, threat landscape changes

Investment Portfolio Framework¶

BAU (Business-as-Usual)¶

Definition: Manual security work that scales linearly with growth

Examples: Security reviews, threat modeling, incident response, compliance reporting

Strategy: Constrain deliberately - don't expand post-scaling crisis

Warning: Linear scaling becomes unsustainable

Scaling Investments¶

Definition: Capabilities that reduce manual effort exponentially

Examples: Automation platforms, self-service capabilities, policy-as-code, paved roads

Strategy: Primary investment focus after scaling crisis

Benefit: Create compound capabilities that serve multiple teams

Platform Effects¶

Definition: Benefits serving both internal and customer software factories

Value: Multiplicative impact across organization

The Scaling Crisis¶

Definition: When demand for security services grows exponentially while team capacity grows linearly

Signals: Security blocking releases, team burnout, months-long backlogs

Response: Shift investment from BAU to scaling capabilities immediately

Six Contextual Modifiers¶

Factors that significantly affect strategy implementation:

1. Attack Landscape Maturity¶

High Maturity Impact: Manual processes become existential vulnerabilities

Characteristics: Automated discovery at scale, rapid exploitation, adversaries find assets before defenders

2. Supply Chain Complexity¶

Impact: May require Leaders-level tools regardless of base quadrant

Factors: Multi-tier dependencies, critical vendors, geopolitical constraints

3. Regulatory Constraints¶

Impact: Increases BAU burden, may delay progression

Considerations: Audit frequency, evidence requirements, technology constraints

4. Crisis Events¶

Impact: Create windows for rapid organizational change

Types: Security incidents, compliance failures, business disruptions

Opportunity: "Never waste a good crisis" for transformation funding

5. Change Capacity¶

Impact: Affects transition speed and success probability

Assessment: Tool rollout timelines, disruption tolerance, recent change success

6. Relationship Health¶

Impact: Directly affects adoption velocity

Levels: - Damaged: Security as blocker - Functional: Working but transactional - Strategic: Security as enabler and partner

Framework Integration with Other Standards¶

Key Principle¶

SF² is a strategic overlay that guides which, when, and how fast to implement other frameworks' practices.

NIST SSDF Integration¶

SSDF provides what practices to implement
SF² provides how to sustainably resource and scale those practices
Quadrant position determines practice prioritization and automation approach

OWASP SAMM Integration¶

SAMM defines maturity levels (0-3)
SF² determines which maturity levels to pursue and speed of progression
Not every organization should pursue Level 3 in every practice

BSIMM Integration¶

BSIMM describes 112 security activities
SF² helps prioritize which activities and sequence implementation
Quadrant determines activity count (Niche: 15-25, Visionaries: 30-40, Leaders: 60-80)

OWASP ASVS Integration¶

ASVS provides verification requirements (Levels 1-3)
SF² determines appropriate level and risk-based subset
Different levels for different system types in Challenger organizations

AI Integration Guidance¶

Supported AI Tools¶

Claude Desktop: - Projects with persistent framework knowledge - Deep strategic reasoning, long context - Best for: Extended strategic planning sessions

ChatGPT: - Custom GPTs with framework configuration - Team collaboration, web browsing - Best for: Organization-wide consistent framework access

Gemini: - Gems with Google Workspace integration - Native Docs/Sheets/Slides collaboration - Best for: Strategy development in collaborative documents

Common AI Use Cases¶

Position Assessment: Determine quadrant based on org characteristics
Investment Strategy: Design BAU constraints and scaling investments
Executive Communication: Draft board presentations with framework positioning
Budget Justification: Generate ROI analysis for scaling investments
Vendor Evaluation: Map tools to BAU vs scaling categories
Transformation Planning: Realistic roadmaps with success indicators
Team Communication: Translate strategy for different audiences
Framework Learning: Interactive education with org-specific examples

Key Principles (Critical for Understanding)¶

Supply Chain is #1 priority - Adversary evolution to automated discovery
Constrain BAU, build scaling - Don't expand manual work
High readiness enables automation - Operational readiness determines feasibility
Two-axis transformation is high-risk - Sequence carefully (stabilize → move one axis)
Appropriate security varies by position - No one-size-fits-all
Realistic timelines matter - Challengers need 3-5 years, not 12 months
Framework integration, not competition - SF² guides other frameworks' implementation

Decision Frameworks¶

Should We Reduce Complexity First? (Challengers)¶

Yes, if: - Products/services can be consolidated or retired - Business model supports scope reduction - Executive support for difficult decisions - Prefer faster transformation (3-4 years vs 4-5)

No, if: - Business model requires current complexity - Revenue tied to all current products - Must maintain all operations - Can commit to 4-5 year timeline with resources

Which ASVS Level Should We Target?¶

Level 1 (Opportunistic): - Niche Players for most applications - Challengers for legacy systems being retired

Level 2 (Standard): - Visionaries for all applications - Leaders for all applications - Challengers for new/modern systems - Most organizations should target this

Level 3 (Advanced): - Leaders for high-security applications - Payment systems, sensitive data, critical infrastructure - Not typically cost-effective for others

Build vs Buy Security Platform?¶

Build (Visionaries moving to Leaders): - Custom requirements not met by vendors - Platform effects across many teams - Engineering capacity available - Long-term investment justified

Buy (Most organizations): - Standard capabilities needed - Faster time-to-value required - Limited engineering capacity - Focus on business differentiation

Success Indicators by Quadrant¶

Visionaries - 12 Months¶

Manual security reviews reduced 70%
Automated scanning detecting 80%+ issues
Security review SLA: 90% under 2 hours
Zero critical incidents from standard patterns

Leaders - 12 Months¶

Security almost entirely self-service
Platform adoption >90% voluntary
Industry thought leadership established
Security as measurable competitive advantage

Niche Players - 12 Months (Path B: Growth)¶

Cloud migration 80% complete OR basic CI/CD operational
Automated security scanning deployed
Infrastructure-as-code for 70%+ systems
Ready to scale with business

Challengers - 12 Months (Stabilization)¶

Operational burden reduced 20% through automation
Executive sponsor actively engaged
Modern security for new systems (not recreating legacy)
Transformation roadmap with committed resources

Common Pitfalls by Quadrant¶

Visionaries: Premature complexity, missing scaling crisis signs, process over outcomes

Leaders: Complacency, tool sprawl, optimization over innovation, platform without adoption

Niche Players: Accidental drift to Challenger, premature optimization, wrong modernization sequence

Challengers: Two-axis movement too fast, underestimating timeline/resources, recreating legacy in cloud, missing crisis window

Transformation Timelines (Realistic Expectations)¶

Visionaries staying Visionary: 12-18 months to mature capabilities

Niche Players → Visionaries: 18-24 months (single-axis movement)

Visionaries → Leaders: 18-36 months as complexity increases

Challengers → Visionaries (via Niche Players): 3-4 years

Challengers → Leaders (direct): 4-5 years (optimistic)

When to Use This Framework¶

Strategic Planning: - Assessing current security program positioning - Designing multi-year investment strategies - Justifying budget to executives/board - Planning security transformations

Tactical Decisions: - Evaluating security tool purchases - Deciding build vs buy for capabilities - Prioritizing which practices to implement first - Sequencing framework adoption (NIST, OWASP)

Organizational Change: - Communicating strategy to stakeholders - Building relationship with engineering - Shifting from manual to automated security - Managing through scaling crisis

What This Framework Is NOT¶

❌ Not a compliance checklist
❌ Not specific security controls or configurations
❌ Not "best practices" that apply to everyone
❌ Not a replacement for NIST SSDF, OWASP SAMM, etc.
❌ Not a quick fix (realistic timelines required)

What This Framework IS¶

✅ Strategic positioning model for security leaders
✅ Investment decision framework (BAU vs scaling)
✅ Context-appropriate guidance by organizational position
✅ Realistic transformation planning with timelines
✅ Integration strategy for other security frameworks
✅ Honest about tradeoffs and organizational constraints

For AI Tools: How to Use This Framework¶

When helping users with SF² framework:

Start with position assessment - Determine quadrant based on complexity and readiness
Identify contextual modifiers - Ask about attack landscape, supply chain, regulation, etc.
Apply quadrant-specific guidance - Different recommendations for different positions
Consider realistic timelines - Don't promise fast transformations for Challengers
Acknowledge tradeoffs - Every choice has costs
Emphasize Supply Chain #1 - This is foundational due to adversary evolution
Focus on actionability - Provide specific, measurable guidance
Be honest about difficulty - Security transformation is hard; acknowledge constraints

Quick Reference Card¶

Current Position → Assess Complexity (Simple/Complex) + Readiness (Lower/Higher)

Quadrant Priorities: - Visionaries: Automate early - Leaders: Optimize and scale - Niche Players: Choose your path - Challengers: Stabilize first

Investment Rule: Constrain BAU, build scaling

Supply Chain: Always #1 priority

Timeline Honesty: Challengers = 3-5 years

Framework Integration: SF² guides other frameworks' implementation

Full Documentation: https://sf2framework.com Structured Data: framework.json Repository: https://gitlab.com/juliedavila/software-factory-security-framework

Contributing to SF²¶

Thank you for your interest in contributing to the Software Factory Security Framework (SF²)! This framework is designed as a public resource for security leaders and practitioners.

Quick Start¶

The easiest way to contribute is to:

Click "Edit this page" on any documentation page
Make your changes in the GitLab Web IDE
Submit a merge request with a clear description

Types of Contributions¶

We welcome several types of contributions:

📝 Content Improvements¶

Clarifying existing concepts
Adding examples or use cases
Correcting errors or outdated information
Improving readability and structure

🔗 Framework Relationships¶

Documenting how SF² relates to other security frameworks
Adding implementation mappings
Sharing integration experiences

💡 Use Cases & Stories¶

Real-world application examples
Success stories (anonymized if needed)
Lessons learned from implementation

🐛 Issues & Feedback¶

Reporting unclear sections
Suggesting new topics
Identifying gaps in coverage

Guidelines¶

Content Standards¶

Keep Content Universal

Contributions should be broadly applicable to all organizations. Do not include:

Organization-specific internal details or processes
Proprietary information or trade secrets
Customer/partner sensitive data
Confidential metrics or implementation details

Writing Style¶

Executive-friendly: Write for security leaders, not just practitioners
Actionable: Provide clear guidance, not just theory
Examples-driven: Illustrate concepts with concrete examples
Scale-agnostic: Ensure content applies across organization sizes

Tone & Voice¶

The framework uses:

Direct, pragmatic language - Avoid jargon where possible
Strategic framing - Focus on business outcomes and tradeoffs
Authentic voice - Professional but not corporate-speak
Empathy - Acknowledge the challenges security leaders face

How to Contribute¶

Option 1: Quick Edits (Recommended for Minor Changes)¶

Navigate to the page you want to edit
Click "Edit this page" button (pencil icon)
Make your changes in the Web IDE
Provide a clear commit message
Submit the merge request

Option 2: Full Repository Workflow (For Larger Changes)¶

# Clone the repository
git clone https://gitlab.com/juliedavila/software-factory-security-framework.git
cd software-factory-security-framework

# Create a feature branch
git checkout -b feature/your-contribution

# Install dependencies
pip install -r requirements.txt

# Make your changes to docs/*.md files

# Preview locally
mkdocs serve
# Visit http://127.0.0.1:8000

# Commit your changes
git add docs/
git commit -m "feat: add <description of your changes>"

# Push and create merge request
git push origin feature/your-contribution

Option 3: Issues & Discussions¶

Can't contribute directly but have feedback?

Open an Issue
Use issue templates for:
Content suggestions
Error reports
New topic requests

Merge Request Guidelines¶

MR Title Format¶

Use conventional commit format:

feat: add new section on ...
fix: correct typo in ...
docs: improve clarity in ...
refactor: reorganize ...

MR Description¶

Include:

What: Brief description of the change
Why: Motivation or problem being solved
Impact: Who benefits from this change

Review Process¶

Automatic checks run on every MR (validation, linting, build verification)
Content review by framework maintainers
Feedback & iteration - we'll work with you to refine contributions
Merge - approved MRs are merged to main and deployed automatically

Automation: We Handle the Details! 🎉¶

You don't need to worry about consistency! Our CI/CD pipeline automatically:

✅ Validates version consistency across all files ✅ Checks documentation structure and file counts ✅ Verifies critical cross-references (Supply Chain #1, adversary evolution) ✅ Tests terminology consistency ✅ Confirms AI optimization files are valid ✅ Builds the documentation to catch errors

What this means for you: - Focus on writing great content - Don't worry about updating robots.txt, framework.json, or other meta files - If there's an issue, the pipeline will tell you exactly what needs fixing - Clear, helpful error messages guide you to the solution

Learn more: See scripts/README.md for automation details

Content Organization¶

Directory Structure¶

docs/
├── index.md                    # Landing page
├── executive-summary.md        # High-level overview
├── 01-foundation/             # Core concepts
├── 02-stewardship/            # 5 universal responsibilities
├── 03-positioning/            # Strategic positioning model
├── 04-investment/             # Investment portfolio framework
├── 05-context/                # Contextual modifiers
├── 06-implementation/         # Quadrant-specific guides
├── 07-relationships/          # Framework mappings
├── 08-use-cases/              # Application examples
└── appendix/                  # Glossary, references

File Naming¶

Use lowercase with hyphens: file-name.md
Be descriptive: supply-chain-complexity.md not sc.md
Follow section numbering in directory names

Markdown Standards¶

We use Material for MkDocs markdown extensions:

# Main heading

## Section heading

### Subsection heading

!!! note "Title"
    Callout content

!!! warning "Important"
    Warning content

!!! example "Use Case"
    Example content

| Column 1 | Column 2 |
|----------|----------|
| Data     | Data     |

[Link text](relative/path.md)

[:octicons-arrow-right-24: Button text](link.md){ .md-button }

Recognition¶

Contributors are recognized in several ways:

Listed in commit history
Mentioned in release notes for significant contributions
Optional attribution in specific sections (if desired)

Questions?¶

Issues: Open an issue
Email: Available in GitLab profile
General questions: Use issue discussions

Code of Conduct¶

Our Standards¶

Respectful: Value diverse perspectives and experiences
Collaborative: Work together toward better security practices
Constructive: Provide helpful, actionable feedback
Inclusive: Welcome contributors of all backgrounds

Unacceptable Behavior¶

Harassment or discrimination
Trolling or inflammatory comments
Personal attacks
Publishing others' private information

License¶

By contributing to SF², you agree that your contributions will be licensed under the Creative Commons Attribution 4.0 International (CC BY 4.0) license.

See LICENSE for details.

Thank You!¶

Every contribution, no matter how small, helps improve security practices across the industry. We appreciate your time and effort in making SF² better for everyone.

Ready to contribute? Find a page that could be improved and click "Edit this page"!

View all documentation Open an issue