Security
The threat model is the starting point, not an afterthought. SILA begins each piece of work by asking what an attacker, a mistake, or a bad day could do, and designs from that answer.
Security Integration & Lifecycle Architecture
SILA
/ˈsiːlə/ · SEE-lah
The route every codnamacs release follows.
SILA is the framework codnamacs uses to keep software safe over time, not at a single moment. It is part standing function, part operating discipline, and part researcher that never stops watching how the world changes. Nothing at codnamacs sets out without it, the same way you do not start a journey without a route.
What SILA is
A standing function, not a final signature.
Most products treat security as a milestone: a review near the end, a checklist before launch, a logo on a page. SILA treats it as a route that the work follows from the first commit to long after release. It is closer to a department than to a document, and closer to a discipline than to a department: a standing way of working that asks, again and again, what can fail after launch.
SILA applies across codnamacs, to every app the studio ships. It watches macOS, OpenSSH, NIST, CWE, CVE, and current cloud-security practice, and it folds what it learns back into how the next release is built. When a new failure mode appears in the wider world, SILA is the part of codnamacs whose job is to notice it early and design around it before it becomes a support mystery.
The rule is simple, and it is not negotiable on a deadline: no route, no release. A build does not move just because the interface is finished. It moves when SILA can answer the lifecycle questions that actually decide whether the software is safe to trust.
The four words
The name is the method.
SILA is not a label chosen to sound serious. Each word is a commitment the framework actually keeps.
Integration
Security is built in at the keystroke level, reviewed while the code is written rather than bolted on for a release page. Alignment is part of how a feature is made, not a label added at the end.
Lifecycle
Every stage is in scope: integrate, review, release, observe, restore, and learn. A feature is not finished when it works; it is finished when its failure modes are understood and covered.
Architecture
Named, public standards give the work a structural frame, so the security posture is something a technical reviewer can read in how the product behaves.
What SILA reviews
Security is the map the work follows.
A codnamacs release is not measured only by what it adds. SILA asks whether access can be removed cleanly, whether backups preserve the right state, whether logs and exports stay quiet where they should, and whether the operator can see enough to trust the system. These are the standing review domains.
Access lifecycle
What happens before access is granted, while it is active, after it is revoked, and after the next restore. Revocation is treated as state that must persist, not a one-time UI action.
Backup and restore behavior
Backups are part of the security model, not a side convenience that can quietly reintroduce old trust. A restore should never resurrect access that was deliberately removed.
Logging and privacy surface
Operational signals stay useful without turning broad system logs into a place where sensitive values accumulate. Each log line is classified for what it is allowed to reveal.
Sensitive-file hygiene
Private keys, encrypted packages, QR files, and exports are reviewed for accidental indexing, preview, backup, and sync exposure across the operating system.
Integrity and release evidence
Tamper-evidence and operator-visible events make important changes easy to find, and each security-facing release leaves behind language a technical reviewer can read.
Continuous research
SILA watches macOS, OpenSSH, NIST, CWE, CVE, and cloud-security practice for shifts that change the threat model, so the framework moves before the threats do.
The standards SILA works against
Evidence you can read, not a badge you take on faith.
SILA aligns its work with named, public security standards, and it produces control evidence that maps to them. That is a deliberate, precise position: SILA is a discipline that yields evidence, and the evidence lives in how the product actually behaves, from how revocation persists to how sensitive files are handled. It gives a technical reviewer something to inspect rather than something to trust.
NIST SP 800-53r5CWESOC 2 Common CriteriaGDPRCIS macOS BenchmarkISO/IEC 27001:2022OWASPNIST SP 800-92NIST SP 800-88 Rev. 1NIST SP 800-52r2NIST SP 800-219CFAA
These names describe alignment and control evidence. They are not a claim of certification, and SILA never presents them as one. The value is verifiable behavior mapped to a shared vocabulary.
SILA in practice
A sample: when SILA caught a gap a feature-first process would miss.
The clearest way to see SILA is to watch it catch something that looks finished but is not. In HearthGate, revoking an SSH key should mean the key never works again. The feature worked. But a backup taken before the revocation could quietly bring that key back on restore, on a new Mac, or after a clean reinstall. A feature-first process calls that an edge case. SILA calls it a lifecycle gap, because revocation is access removal, and access removal that a restore can undo is not really removal.
The answer was defense in depth across four independent layers, so a revoked key stays revoked across a .hgex restore, a different machine, and a freshly installed operating system. The same lens then shaped the rest of the release: privacy-aware logging that keeps sensitive values out of broad system logs; a pre-auth access notice shown before SSH and at the macOS login window; and forensic-metadata hygiene that keeps private keys and backups out of Spotlight, Quick Look, Time Machine, and iCloud.
Each of those carries named control evidence: CWE-672 for the revocation gap, CWE-532 for logging privacy, CWE-552 and CWE-200 for sensitive-file exposure, NIST SP 800-53r5 access, audit, and integrity families, SOC 2 access-removal criteria, and GDPR Article 32 language. The full per-feature mapping lives with the release notes; the point on this page is the habit behind it. SILA looks for what fails after launch, and treats the answer as part of the product rather than a footnote.
Why it is mandatory
codnamacs does not ship off-route.
SILA is not a stage a release can skip when a date is close. It is the route itself, and a route is the one thing you do not leave behind when the deadline gets loud. A build that has not been through SILA is a build that cannot yet answer the question SILA exists to ask: what can fail after this ships?
That is what makes SILA a framework rather than a feeling. It is the standing reason codnamacs software behaves like a security product should after launch, not just on the day it was demonstrated. The newest HearthGate release is the clearest place to see it at work.