SnowBe Online Secure Software Development Life Cycle Plan
This plan selects the NIST Secure Software Development Framework (SSDF) over Microsoft SDL for SnowBe Online, a fast-growing retailer building its first development team. It defines a project manager plus three specialized developers, recommends Agile Scrum with DevSecOps, and lays out a 90-day implementation roadmap.
By Sean Richard
At a glance
- Scenario
- SnowBe Online grew $100M in three years on AWS-hosted sales, a WordPress storefront, on-premise servers, and business apps, with PCI obligations and CEO concern about software supply-chain risk.
- Decision
- Adopt NIST SSDF as the secure development framework over Microsoft SDL: broad, vendor-neutral, and easier for a new three-person team to operationalize.
- Design
- A project manager plus three specialized developers (architect and security champion, DevSecOps engineer, test and vulnerability response), working in Agile Scrum with DevSecOps.
- Outcome
- A 90-day implementation roadmap: foundation, design and pilot, operationalize.
The problem: business success, software gaps
SnowBe processes most of its sales online through AWS and runs stores in the U.S. and Europe. The same environment keeps customer information indefinitely, allows broad access across servers and applications, and has gaps in WordPress maintenance, patching, firmware, anti-virus, and backups, on top of PCI obligations. The plan draws three conclusions for development:
- SnowBe cannot treat software as a side project. It needs a secure, repeatable development model that supports growth and compliance.
- The framework has to work across cloud systems, web applications, internal business tools, and third-party components.
- A small new team needs structure first, then speed. Security has to be built in before the first release.
How the framework decision was made
- Start with risk: online payments, stored customer data, weak access control, PCI exposure, and supply-chain concern.
- Compare frameworks: SSDF and Microsoft SDL both support secure development, but they organize adoption differently.
- Check team maturity: the project lead is building a three-person team from scratch, so the framework must be easy to operationalize.
- Test environment fit: SnowBe spans AWS, WordPress, on-premise servers, remote laptops, and business apps.
- Select the long-term fit: the choice had to support immediate control needs and future software growth.
In one sentence: SnowBe needed a framework that was broad, practical, vendor-neutral, and easier to adopt for a small new team, and that combination pointed to SSDF.
NIST SSDF vs Microsoft SDL for this case
| Criteria | Microsoft SDL | Why SSDF won |
|---|---|---|
| Adoption starting point | Strong for mature engineering practice | Easier for a new team building process from zero |
| Environment fit | Excellent, but reads as more platform-centered | Broad fit across AWS, WordPress, on-premise, and custom tools |
| Governance alignment | Would require translation into SnowBe's current direction | Naturally matches the NIST language already in use |
| Small-team practicality | Good, but heavier to socialize from scratch | Simpler to translate into roles, responsibilities, and checkpoints |
| Decision result | Not rejected as weak | Chosen because it is the better fit now |
Microsoft SDL remains a credible framework. It was not the best starting framework for SnowBe's current maturity, team size, and operating context. SSDF's four practice groups gave the new team a clean operating model: prepare the organization, protect the software, produce well-secured software, and respond to vulnerabilities.
Team design: a lead plus three specialized developers
The point is not a large team. It is a small team with clear ownership.
| Role | Owns |
|---|---|
| Project Manager and Secure Development Lead | Leads the team and the secure development process |
| Application Architect and Security Champion | Secure design and trust boundaries, secure coding standards and dependency review, and authentication, authorization, and data protection choices |
| DevSecOps and Build Engineer | Repositories, secrets, and CI/CD protection, scanning and release controls, and reducing software supply-chain risk before deployment |
| Test and Vulnerability Response Engineer | Validating requirements through testing and logging checks, tracking defects and remediation, and capturing root-cause findings |
Methodology and the first 90 days
Agile Scrum with DevSecOps makes security a normal sprint activity instead of a late review gate: plan with a threat model, design with a review, build with scanning, test, then release with monitoring. Waterfall is too rigid for an immature process, and RAD alone can create speed without enough security discipline.
- Days 1 to 30, set the foundation: confirm security requirements, assign roles and approval points, and stand up repositories, branch protections, and secure build basics.
- Days 31 to 60, design and pilot: run initial threat modeling on the first product scope, choose approved libraries and document dependency rules, and begin sprint-based development with review and testing gates.
- Days 61 to 90, operationalize: add automated scanning, logging checks, and release controls, track vulnerabilities and remediation deadlines, and adjust team practices before scale-up.
The closing recommendation is that secure software is a management decision, not only a technical one. If SnowBe builds the framework, the roles, and the sprint discipline correctly now, it will spend less time repairing avoidable security debt later.
What this project demonstrates
- Choosing a secure development framework from risk, team maturity, and environment fit.
- Comparing NIST SSDF and Microsoft SDL without dismissing the alternative.
- Designing a small DevSecOps team with clear ownership of design, build, and testing.
- Turning a framework decision into a 90-day operating plan.
Read the full document
Portfolio edition of coursework completed for the B.S. in Cyber/Computer Forensics & Counterterrorism at Full Sail University. The organization and scenario are a course case study, and this page summarizes the full document.