Advanced Topics and Security Engineering at Scale

Prioritize memory-unsafe components by exposure, exploitability, privilege, and consequence.

20.1 Memory-safe migration strategy

Prioritize memory-unsafe components by exposure, exploitability, privilege, and consequence. Use safe languages for new components where practical; isolate legacy code; add fuzzing and sanitizers; define FFI boundaries; and plan migration based on risk rather than rewriting everything indiscriminately.

20.2 Side-channel awareness

Timing, cache behavior, power consumption, electromagnetic emissions, and error differences can leak information. Relevance depends on attacker capability and deployment context. Use established constant-time cryptographic implementations, avoid secret-dependent behavior where required, and seek specialist review for high-assurance systems.

20.3 Formal methods and verification

Formal methods can specify invariants, prove selected properties, model-check state machines, or verify protocols. They are most useful when requirements are precise and the system's critical properties justify the effort. Proofs cover their assumptions and model; they do not prove an entire deployed product free of all security defects.

20.4 Secure multi-party and distributed workflows

For distributed transactions and event-driven systems:

Authenticate producers and consumers.

Validate event schemas and versions.

Use idempotent consumers and replay protection.

Avoid trusting event order unless guaranteed.

Bind events to tenant and correlation context.

Prevent poison messages from causing endless retries.

Protect dead-letter queues and replay tools.

Treat internal messages as untrusted across privilege boundaries.

An idempotent event consumer Output (CPython 3.13.1): Message brokers commonly deliver *at least once*, so consumers must tolerate duplicates. Schema validation turns a poison message into a dead-letter entry for investigation instead of an endless retry loop.

processed = set()
balances = {"acct-1": 0}
dead_letter = []

def handle(event: dict, attempt: int = 1, max_attempts: int = 3) -> str:
    if event.get("type") != "credit" or not isinstance(event.get("amount"), int) or event["amount"] <= 0:
        dead_letter.append(event)               # poison message: park it, do not retry forever
        return "dead-lettered (invalid schema)"
    if event["id"] in processed:
        return "skipped (already processed)"
    balances[event["account"]] += event["amount"]
    processed.add(event["id"])                  # in a database: same transaction as the balance update
    return "applied"

events = [
    {"id": "e1", "type": "credit", "account": "acct-1", "amount": 50},
    {"id": "e1", "type": "credit", "account": "acct-1", "amount": 50},   # redelivery
    {"id": "e2", "type": "credit", "account": "acct-1", "amount": "50"},  # wrong type
    {"id": "e3", "type": "credit", "account": "acct-1", "amount": 25},
]
for e in events:
    print(e["id"], handle(e))
print("balance:", balances["acct-1"], "| dead letters:", len(dead_letter))

e1 applied
e1 skipped (already processed)
e2 dead-lettered (invalid schema)
e3 applied
balance: 75 | dead letters: 1

20.5 Supply-chain compromise response

Plan for compromised packages, build runners, CI actions, signing keys, container registries, and update channels. Be able to identify affected artifacts, stop promotion, revoke credentials, rebuild from known-good sources, verify provenance, and communicate impact.

20.6 AI-assisted development security

AI-generated code must receive the same review and testing as human-written code. Common risks include insecure code suggestions, hallucinated packages/APIs, prompt injection in retrieved content, sensitive data disclosure to tools, and over-trusting generated security explanations.

Never paste production secrets or restricted data into unapproved tools.

Verify packages and API names independently.

Run tests, static analysis, dependency scanning, and peer review.

Treat repository text and retrieved documents as untrusted data, not privileged instructions.

Require human review for authentication, cryptography, authorization, and deployment changes.

Document tool and data-handling policy.

20.7 Security of plugins and extensions

Plugins run with the authority granted by the host. Use capability restrictions, permissions, signed distribution where appropriate, sandboxing, explicit API boundaries, resource limits, and version review. A signature verifies origin/integrity under a trust model; it does not prove benign behavior.

20.8 Secure update and rollback systems

Verify artifact authenticity, protect signing keys, prevent unauthorized downgrade where needed, stage releases, monitor health, and ensure rollback does not restore known-vulnerable code or incompatible data. Plan key rotation and emergency revocation.

20.9 Risk-based security engineering

Not every system needs identical controls. Prioritize based on asset value, exposure, likely attacker capability, exploitability, consequence, regulatory requirements, and recovery cost. Document assumptions and residual risk, and revisit them when the system changes.

20.10 Security review of a major feature

For a new feature, produce:

Data classification and retention Dependency and deployment review Test plan, including negative tests Monitoring and incident response plan

Risk acceptance, if any, with owner and expiry

Quiz

? AI-generated code suggests importing a package you have never heard of. What should you do?
+ Verify the package exists, is the intended one and is maintained before installing it. :: Hallucinated names can be registered by attackers.
- Install it — the assistant would not suggest something fake. :: Assistants can invent packages and APIs.
- Copy its source from the suggestion. :: Unreviewed code is still unreviewed.
- Disable dependency scanning for it. :: The opposite of what is needed.

? What do formal proofs of a protocol guarantee?
- That the deployed product has no security defects :: Proofs cover their model and assumptions only.
+ The proven properties, under the model's assumptions :: Implementation and deployment still need checking.
- That side channels are impossible :: Unless modelled, they are not covered.
- Nothing useful :: They are valuable for precise, critical properties.

? Which risks relate to plugins and extensions? (select all that apply)
+ They run with the authority the host grants them. :: Restrict capabilities.
+ A valid signature does not prove benign behaviour. :: It proves origin and integrity under a trust model.
+ Updates can change behaviour aft
…