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 D1, distinguishing order information from published records. Minimize the attack surface and apply appropriate access controls |
| Implementation | Secure coding, code review | Local git history, code review, and validation. Visitors can inspect code delivered to their browsers. |
| Testing | Vulnerability scanning, penetration testing | Static delivery limits the attack surface; APIs, dependencies, and settings require separate validation |
| Deployment | Configuration management, access control | Direct deployment from a MacBook to Cloudflare Pages, with review before deployment and verification afterward |
| Operations | Monitoring, incident response | Local git records change history for review. Operational data and the deployed environment require separate checks |
What stands out is that TokiStorage's SSDLC is not an approach of "adding security measures" but of "choosing an architecture that structurally reduces security risks."
Order processing uses Cloudflare Workers and D1. Order information is distinguished from records published or replicated for long-term preservation, with publication governed by the customer’s choices. Preservation combines physical media, community-distributed nodes, and deposit at Japan’s National Diet Library. Code and change history are managed in local git repositories, and static sites are deployed directly from a MacBook to Cloudflare Pages. Static delivery still requires review and validation of APIs and dependencies.
This is not "fortifying the walls." It is a design philosophy of "minimizing the walls that need fortifying."
5. Publication Scope and Responsibility for Validation
Security validation requires clarity about what is public and what can be checked. Being able to inspect some code does not establish the security of the entire system.
TokiStorage emphasizes consistency between public explanations and actual development and validation practices.
Visitors can inspect the HTML, CSS, and JavaScript delivered to their browsers. This does not mean that all source code or internal history is public. The publication scope must be clear, and internal review and validation remain necessary.
Security explanations must identify the checks actually performed and their scope. Inspecting delivered code alone cannot establish the security of operational settings, APIs, or the system as a whole.
A publicly accessible site does not constitute a third-party audit. Review, testing, and checks after publication must distinguish verified findings from areas that have not been examined.
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 records are separated from any single company's service and preserved across media and locations
- 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.
Changes are tracked locally and reviewed and validated before publication.
Ethics is practiced through everyday development work.