jperezduerto.info
Security in depth · Unit 21 · Lesson 6 of 6
Memory safety is not all security
Map memory guarantees, native dependencies, and document permissions separately.
Helpful before thisMemory safety: boundaries and lifetimes
After this lesson you can
- Assign different security requirements to a native-code boundary and an application access decision.
One idea. One situation. One reasoned decision.
How it works
A memory-safe language can prevent or constrain important classes of memory errors, depending on its implementation and use of unsafe features or native dependencies. It does not automatically enforce business permissions, protect secrets, or validate every external interaction. Review boundaries with native code and generated data, and keep application security requirements explicit. Choosing safer foundations reduces work; it does not eliminate design responsibility.
One language choice, several obligations
A fictional document service uses a memory-safe application language. Its design review provides three records:
| Record | Design detail |
|---|---|
| S1 | Application code uses the language’s checked memory facilities |
| S2 | Image conversion calls a separately maintained native library |
| S3 | Document requests check sign-in, but omit the document membership rule |
Worked decision: retain the benefit in S1 while opening two distinct reviews. S2 needs a review of the native interface’s ownership and size contract, supported-library status, and relevant tests. S3 needs enforcement of the intended document access rule for each request. A user being signed in does not establish membership of that document.
Moving application code to a safer memory model does not automatically extend every guarantee to native dependencies. Nor does repairing an access rule show that the native interface is correct. Give the two concerns separate acceptance evidence and owners.
For S3, a useful acceptance record includes both an allowed member request and a denied nonmember request under the stated policy. For S2, request evidence tied to the actual dependency and interface contract. These checks test different properties; neither is a substitute for the other.
The key distinction: Different security properties require different controls.
Check yourself
No timer. No penalties. Read the explanation and try again whenever you like.
This lesson’s questions have changed. Your reading progress is saved; review the updated questions.
-
What is the most defensible review plan for S1-S3?
Show the answer
Correct answer: Review the native boundary and enforce document membership as separate obligations. S1 provides a useful memory foundation. S2 and S3 still concern different properties that need their own evidence and acceptance criteria.
Try it
- WriteCreate a two-row review note for S2 and S3. Give each a security property, responsible owner, and evidence that would justify closing that specific concern.