1. What Is SSDLC
SSDLC (Secure Software Development Lifecycle) is a development approach that embeds security into every stage of software: planning, design, implementation, testing, and operations.
In traditional development, security was "something added at the end." Write the code, finish the features, run a security check before release. Fix problems if found.
SSDLC inverts this sequence. It defines "what must be protected" at the design stage, with security as a premise at every step. Security becomes not a retroactive measure, but the design philosophy itself.
Major technology companies including Microsoft, Google, and Apple have adopted this approach, and it is established as an industry best practice.
2. Why It's Usually Discussed as "Cost"
For most companies, SSDLC is an additional cost. Security reviews take time. Threat modeling requires personnel. Penetration testing costs money.
And above all, investing in security doesn't add visible features. When users are told "this product is SSDLC-compliant," they don't know what changed.
This is why many startups defer SSDLC. Build features first, acquire users, and "think about security when problems arise."
But this calculus is only justified when the data being held is "replaceable."
3. When What You Hold Changes, Security's Meaning Changes
When an e-commerce site leaks credit card information, cards can be reissued. When a social media account is hijacked, accounts can be recreated. The damage is serious, but "substitutes" exist.
What TokiStorage holds cannot be substituted.
- A human voice — can only be recorded while that person is alive
- A record of existence — the customer's story, feelings, and reasons for their choice
- A path to the national record — a pipeline connected to the National Diet Library's permanent archive
If this pipeline had a vulnerability and data were tampered with. If someone's voice were swapped. If the newsletter records were rewritten.
That would not be a "data breach." It would mean that person's proof of existence had been contaminated.
A credit card can be reissued.
A voice may never be re-recorded.
The voice of someone already gone — never.
4. TokiStorage's SSDLC
| Phase | General SSDLC | TokiStorage's practice |
|---|---|---|
| Design | Threat modeling, security requirements | Architecture where permanent data (voice, images) is self-contained within the QR code. Operational tasks (orders, inquiries) use Cloudflare Workers and GAS, but all data in the pipeline is public by destination — no secret data exists. Fundamentally minimizing the attack surface |
| Implementation | Secure coding, code review | All code published on GitHub. Anyone worldwide can perform code review. Verifiable absence of hidden backdoors |
| Testing | Vulnerability scanning, penetration testing | Static site architecture structurally eliminates entire categories of server-side vulnerabilities |
| Deployment | Configuration management, access control | Automated CI/CD deployment via GitHub Pages. Eliminates human error risk of manual deployment |
| Operations | Monitoring, incident response | Git change history records and tracks every modification. Tampering is immediately detectable |
What stands out is that TokiStorage's SSDLC is not an approach of "adding security measures" but of "choosing an architecture where security risks structurally cannot arise."
No secret data exists in the pipeline. Voice data in QR codes does pass through Cloudflare Workers and GAS as part of order processing, but that data is destined for physical products, GitHub publication, and NDL deposit — it is public by design. Credit card information is processed directly by Wise and never enters the pipeline. The pipeline carries no secrets. If code is published, hidden vulnerabilities will be found. If the site is static, server-side vulnerabilities don't exist.
This is not "fortifying the walls." It is a design philosophy of "minimizing the walls that need fortifying."
5. The Synergy of Open Source and SSDLC
In traditional SSDLC, security verification is performed by internal teams. From the outside, you can only trust the announcement that "this software is secure."
TokiStorage is different. All code is published on GitHub.
This is equivalent to opening the SSDLC verification process to the entire world. Security researchers, developers, anyone with interest can read TokiStorage's code, search for vulnerabilities, and report them.
There is no need to claim "it's secure." Whether it's secure can be verified by anyone.
This structure achieves the final stage of SSDLC — "third-party audit" — at zero cost, permanently. Not a one-time audit commissioned from an auditing firm, but continuous audit by eyes around the world.
6. Security on a 1,000-Year Scale
Typical SSDLC assumes a product lifecycle of a few years to a decade. TokiStorage aims for preservation spanning 1,000 years.
On a thousand-year scale, security concerns transform.
- Encryption algorithms become obsolete — there is no guarantee that today's encryption will be secure in 1,000 years. That's why TokiStorage's security is guaranteed by structure, not by reliance on encryption
- Companies may not survive — that's why the code is published and anyone can fork it
- Platforms will change — that's why data is self-contained within QR codes, with no dependency on any specific platform
This goes beyond the category of "security measures." It is existential design to ensure data remains safe a thousand years from now.
7. Conclusion — Ethics in Every Line of Code
Security is not a cost. It is ethics.
A vulnerability in code that holds proof of human existence
means putting that person's voice at risk.
For many companies, SSDLC is a checklist. Meet the requirements, pass the audit, prove compliance. That's valid. But for TokiStorage, SSDLC is something else.
What's being held is someone's voice. The voice of someone who decided "my existence is worth preserving." A voice that may never be re-recorded. Perhaps the voice of someone no longer in this world.
To leave a vulnerability in that code is to betray that person's decision.
That is why security is not something added at the end but designed from the start. Not a cost but an ethics. Not a checklist but a philosophy.
And that code is published on GitHub for the entire world to see.
Whether this ethics is genuine — anyone can verify for themselves.