Mora Gozani

Mora Gozani

August 29, 2025

This is the second installment in our comprehensive series on the SDLC Security Maturity Model. Building on our introduction to the complete framework, we're diving deep into the first phase that makes everything else possible.

Every software development lifecycle (SDLC) security transformation journey begins with a moment of clarity. That moment when you finally see your development environment as it truly is—not as you assumed it was, not as it was designed to be, but as it actually operates today. This SDLC clarity isn't just powerful; it's the catalyst that enables every subsequent improvement in your security program.

Welcome to the SDLC Security Maturity Model Phase 1: Establishing Your Security Baseline—where knowledge becomes your greatest security asset.

Why Phase 1 is Your Strategic Foundation

Most organizations rush to implement security controls, buy the latest tools, or automate their processes. But the organizations that build truly resilient SDLC security programs? They start by investing in a deep understanding of developer behavior, agile engineering processes, and the technology stack used to enable them. They recognize that Phase 1 of SDLC security maturity isn't a hurdle to overcome—it's the insight and intelligence gathering that makes every future security investment more effective.

SDLC Security Maturity Model Phase 1 provides the foundation for your entire maturity journey. You cannot effectively close gaps (Phase 2) without knowing what SDLC gaps exist. You cannot scale security with consistency (Phase 3) without understanding what you're scaling across. You cannot automate intelligently (Phase 4) without clean, well-understood processes to enhance your SDLC.

I. Identity Discovery and Access Assessment: Who Can Touch Your Code?

The first component of SDLC Security Maturity Model Phase 1 digs deep into every identity that can impact your software development lifecycle. This isn't just about making lists—it's about understanding the full scope of access, permissions, and behaviors that create your security framework.

Identifying All Human and Non-Human Identities

Your development environment is accessed by a complex web of identities. Internal developers are just the starting point. Contractor developers, who have a significantly riskier profile, often have identical access to your full-time team—they commit code, modify pipelines, and access sensitive repositories just like employees, but they're tracked differently (if at all) and their access often persists long after contracts end.

Beyond human users, your SDLC ecosystem relies heavily on non-human identities that often escape traditional monitoring. Service accounts power your automation—from build processes to deployments. Bot tokens enable integrations between tools. Third-party applications connect to your development infrastructure, each with its own access rights. Security tool vendors need repository access for scanning, QA automation requires test environment permissions, and integration partners need API access for their services to function.

These non-human identities create unique challenges. Unlike human accounts that follow predictable lifecycle patterns, service accounts and bot tokens often persist indefinitely, accumulate permissions over time, and operate outside standard identity management systems. Their access and activity becomes harder to monitor with traditional dev tools, creating shadow identities that drift further from governance over time.

Why does this granular identification matter? Because each identity type has different risk profiles, management requirements, and lifecycle patterns. A service account with overly broad permissions poses a different risk than a former employee's lingering access. An unmonitored bot token presents different challenges than a vendor integration. Understanding these distinctions enables targeted remediation in Phase 2.

Unmapped Identities and Corporate IAM Gaps

One of SDLC Security Maturity Model Phase 1's most critical discoveries involves identities that exist outside your corporate identity management system. These shadow identities often include local accounts created directly in development tools, shared accounts that teams use for convenience, and legacy automation accounts whose original creators have long since left.

These unmapped identities represent significant risk because they bypass your standard security controls—no multi-factor authentication, no regular access reviews, no automatic deprovisioning. They're invisible to your security team until Phase 1 brings them to light.

The Identity Correlation and Segregation Challenge

Phase 1 reveals a critical governance gap: while traditional IGA solutions handle joiner-mover-leaver scenarios, they often miss the segregation of duties violations that occur across your development toolchain. A single developer might be "jsmith" in your source control, "john.smith@company.com" in your CI/CD platform, "js-admin" in your artifact repository, and "john_s" in your secret management system.

Without correlating these identities across tools, you can't detect when the same person has conflicting roles that violate segregation of duties policies. Can the developer who writes code also approve their own pull requests under a different account? Does someone with production deployment access also have the ability to modify audit logs? Can the same identity both create and approve pipeline changes?

This identity fragmentation creates both compliance and security risks. You might have policies requiring separation between development and production access, but without identity correlation, the same person could hold both roles under different usernames. Phase 1 must map these identity relationships to reveal where risk management policies are being circumvented, enabling proper segregation enforcement in later phases.

Discovering Inactive Accounts and Access Patterns

Phase 1 of the SDLC Security Maturity Model requires examining not just who has access, but who's actually using it. Inactive accounts aren't just former employees—they include current employees who've changed roles or organizations, automation that's been replaced but not removed, and test accounts that were "temporary" three years ago.

But discovery goes deeper than activity status. You need to gain visibility into basic access levels and activity patterns. This means understanding not just that someone has access, but what level of access they have. Can they read code? Commit changes? Modify pipeline configurations? Delete repositories? Each permission level represents a different risk and requires different controls in later phases.

Detecting Risky Developer Behaviors

Phase 1 must also surface dangerous behavior patterns that indicate either security risks or process breakdowns. This includes developers bypassing established guardrails using their elevated access, unauthorized code merges that skip review processes, access from unusual locations or at unusual times, and bulk data exports that could indicate exfiltration.

Why do these behaviors matter? They're often the first indicators of compromised accounts, insider threats, or simply broken processes that create SDLC security gaps. A developer suddenly accessing repositories outside their normal work pattern might indicate account compromise. Regular bypassing of security controls suggests either misconfigured systems or deliberate circumvention. Phase 1 discovers these patterns so Phase 2 can address both the behaviors and their root causes.

II. Toolchain Inventory: Your Development Infrastructure Reality

The second component of the SDLC Security Maturity Model Phase 1 creates a comprehensive map of your development infrastructure. This goes far beyond listing tools—it's about understanding your entire developer ecosystem and how all the pieces interconnect to enable software creation, testing, and delivery.

Comprehensive Repository and Artifact Discovery

Creating a complete inventory of code repositories sounds straightforward until you actually try it. Beyond your main repositories, Phase 1 uncovers archived projects that still contain sensitive code, experimental repositories that accidentally went public, forked repositories that diverged from security standards, and personal repositories that contain company code.

Artifact repositories add another layer. These include container registries, package repositories, binary storage systems, and build artifact stores. Each represents both a critical component of your development ecosystem and a potential SDLC security gap.

CI/CD Pipeline and Build System Documentation

Documenting all CI/CD pipelines reveals the true complexity of modern software delivery. Official pipelines are just the beginning. Phase 1 discovers shadow pipelines teams created to work around bottlenecks, legacy pipelines still deploying to production, experimental pipelines with production access, and emergency pipelines that bypass security controls.

Understanding build systems and deployment processes means mapping not just what exists, but how it all connects. Which repositories can trigger which pipelines? What can each pipeline access? Where can it deploy? These connections often reveal surprising security implications.

Critical Repository Identification and Ownership

Not all repositories are equal. Phase 1 of the SDLC Security Maturity Model must identify which repositories contain sensitive code—customer data processing, payment systems, authentication mechanisms, proprietary algorithms, or security controls themselves. These critical repositories require stronger controls in subsequent phases.

Repository ownership and maintenance status often reveals organizational gaps. Who's responsible when something breaks? Who approves changes? Who reviews security alerts? Orphaned repositories with unclear ownership represent both operational and security risks.

Access Control Documentation

Understanding current repository protection settings provides the baseline for improvement. This includes branch protection status, required reviewers, commit signing requirements, and merge restrictions. But it goes deeper—who can change these settings? Who can override them?

Documenting who can make changes to repositories, artifacts, and build configurations reveals your true security posture. Read access is one thing, but write access to code, configuration access to pipelines, and administrative access to development tools each represent escalating levels of risk.

III. Code Security Evaluation: Your Current Defense Reality

The third component of Phase 1 assesses your code security measures—examining how you currently scan, validate, and protect the actual code flowing through your development pipeline.

Current Vulnerability Scanning Capabilities

Identifying current vulnerability scanning capabilities means understanding not just what tools you own, but where they're actually deployed and how they're configured. Many organizations discover they have sophisticated scanning tools that only cover a fraction of their repositories, or that scans run but nobody reviews the results.

This evaluation must cover different types of scanning—static application security testing (SAST), dynamic testing (DAST), software composition analysis (SCA), infrastructure as code scanning, and container scanning. Each type addresses different risks and requires different integration points.

Secrets Detection Methods

Documenting secrets detection methods in use reveals critical gaps. Basic pattern matching catches obvious passwords but misses API keys that don't follow standard formats. Historical secrets lurk in commit histories. Encrypted secrets still pose risks if encryption keys aren't properly managed.

Understanding your current capabilities helps prioritize improvements. Can you detect secrets before they're committed? Do you scan commit histories? Can you automatically rotate compromised secrets? Each capability represents a maturity level that Phase 1 documents.

Code Analysis Coverage and SBOM Generation

Understanding code analysis tools and coverage reveals the reality of your application security program. Which repositories have scanning enabled? What types of issues can your tools detect? How are findings tracked and remediated? Phase 1 of the SDLC Security Maturity Model often reveals that security tools generate thousands of findings that nobody addresses—noise that drowns out real risks.

Cataloging Software Bill of Materials (SBOM) generation capabilities has become critical for software supply chain security. Can you generate SBOMs? For which applications? In what formats? How current are they? This baseline enables you to build comprehensive supply chain security in later phases.

Security Testing Documentation

Documenting existing security testing in your pipelines reveals where security actually influences development. This includes automated security gates, manual security reviews, penetration testing integration, and compliance validation. Understanding the current state helps identify where security slows development unnecessarily and where it's missing entirely.

IV. Why These Specific Phase 1 Steps Matter

Each element of Phase 1 serves a specific purpose in your security transformation:

Phase 1 Element Strategic Purpose Impact on Your Journey
Identity discovery Reveals who and what can actually touch your code You cannot manage access you don't know exists
Unmapped identity detection Finds accounts outside your identity management system No MFA, no access reviews, no automatic deprovisioning
Identity correlation mapping Connects the same person across different tool accounts Without correlation, you leave gaps in offboarding and access reviews
Inactive account discovery Surfaces unused access across your environment Quick wins that reduce attack surface and often save money
Risky behavior detection Identifies policy violations and suspicious activities Catch problems early instead of during incidents
Access level documentation Creates the foundation for least-privilege You cannot right-size permissions you don't understand
Repository inventory Ensures nothing falls through the cracks Security only works when it covers everything
Pipeline documentation Maps how code actually reaches production Reveals both official and shadow paths
Ownership mapping Establishes clear accountability Security without ownership always fails
Protection settings assessment Baselines your current controls You cannot improve what you haven't measured
Scanning capability evaluation Reveals underutilized investments Most organizations already own what they need
Secrets detection assessment Identifies your highest-impact quick win Hardcoded secrets remain a top breach cause
SBOM capability documentation Prepares for supply chain requirements Regulatory compliance is becoming mandatory

V. The Compound Effect of Complete Discovery

The value of Phase 1 becomes clear when you find patterns like this: an inactive developer account with admin privileges (identity finding) can still approve pull requests in repositories with permissive settings (toolchain finding), allowing code with hardcoded secrets or known vulnerabilities to merge without review (code security finding).

Each finding alone seems manageable—just another inactive account, just another misconfigured repository, just another instance of secrets in code. But Phase 1's holistic view reveals how these individual issues compound into critical security exposures. That inactive admin account becomes the trusted insider that attackers impersonate. The permissive repository settings become the open door they walk through. The hardcoded credentials or unpatched dependencies become the keys to your kingdom.

This is why Phase 1 of the SDLC Security Maturity Model requires discovering all three pillars together—miss any piece, and you miss the real risk.

VI. From Discovery to Action

Phase 1 transforms overwhelming findings into clear priorities. Your discoveries should naturally organize into three categories:

Critical fixes you handle immediately: When Phase 1 reveals dangerous patterns, you act now. Ex-contractors still accessing sensitive code. Former employees with production system access. Service accounts with admin privileges and no owner. Developers regularly bypassing branch protections on critical repositories. These discoveries require immediate action—document the fix and continue discovery, but don't wait for Phase 2.

Quick wins that save money: Phase 1 always uncovers waste. Unused identities across your tools—both human and machine—that you can immediately revoke, often saving significant license costs. Redundant tools nobody remembers purchasing. Overly complex processes that frustrate developers. These quick wins provide immediate value while you plan broader improvements.

Systematic improvements for Phase 2: The bigger patterns—missing offboarding processes, inconsistent identity management across tools, unclear ownership models—become your Phase 2 roadmap. These aren't random fixes; they're the foundation for scalable security.

Phase 1's genius is organizing chaos into clarity. Instead of reacting to the latest security alert, you're building strategically based on real data about your actual environment.

Starting Your Phase 1 Journey

Begin with commitment to time-boxed discovery. Four weeks of good discovery beats six months of perfect documentation. Use automation where possible—APIs and scripts for data collection, human insight for analysis and planning.

Focus on understanding your current reality without judgment. This isn't about finding fault—it's about establishing the baseline that enables systematic improvement.
Remember: every advanced security program started with Phase 1. The organizations that skip it build on assumptions rather than reality. Those assumptions eventually collapse, usually at the worst possible time.


Next in our series: Phase 2: Closing Gaps and Expanding Visibility—where we transform Phase 1's insights into systematic improvements that reduce risk while enabling development velocity.

Ready to accelerate your Phase 1 discovery? Our 48-hour SDLC Risk Assessment jumpstarts your journey with automated discovery tools and expert analysis. We also provide a comprehensive Phase 1 Discovery Checklist to guide your team through each step of the process. Learn more at [blueflagsecurity.com/risk-assessment].

SDLC
Security

Get the best of our blog