Security: Threats & Defense · Study deck
IoT Software Vulnerabilities
Picture a field app that accepts a temperature value far outside the device range and then draws it as a real alarm.
Shield Shelly is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Explain: The deeper layer covers the classes that need more than a single control check: memory safety in native code, how injection and deserialization arise, supply-chain exposure, and the development process that keeps findings from recurring.
- Explain: In a browser-facing IoT dashboard, the HTML-output version of that failure is cross-site scripting (XSS) or HTML code injection: attacker-controlled text is rendered as markup or script instead of inert content.
- Explain: A software finding is reviewable only when it names the affected path, the security property, and the weak control, and is closed after retest.
Major section
Start With The First Bug Report
The support worker sees a bad screen; the software owner must find where untrusted input became trusted state and what property was lost.
- A fix passes only when the normal path still works and the harmful path is rejected with a useful record.
- A software update is not proof of safety.
- The changed code, built package, installed version, settings, and running service must match.
Major section
Overview: Software Sits Between Everything
A weak parser, an unsafe input path, a missing authorization check, a vulnerable dependency, or an unclear remediation process can expose data or change device behavior.
- This chapter keeps the review defensive.
- The goal is not attack procedure.
- The first scoping move is to name the boundary where data becomes trusted.
Major section
Overview: Software Sits Between Everything (continued)
This map is the chapter's running discipline: every broad vulnerability label must become a specific path, control, and observed result.
- That may be an HTTP handler, MQTT topic, gateway parser, dashboard renderer, update manifest, or dependency imported into a reachable service.
- Once the boundary is named, the finding can point to the exact validation, authorization, encoding, monitoring, or dependency-control evidence that is missing.
- If you can describe a reviewable finding, you can stop here.
Major section
Overview: Software Sits Between Everything (continued)
A vulnerability class is a category of leak: a cracked joint is an input-handling flaw, an unlocked valve is an authorization flaw, and an old corroded pipe is a vulnerable dependency.
- You do not fix "the plumbing." You fix the specific joint and then pressure-test it, which is the retest.
- The input boundary identifies where untrusted data enters; authorization decides whether the authenticated actor may perform the requested action; dependency and data-store checks expose inherited and retained risk.
- Classes are questions Vulnerability classes are defensive prompts to ask better questions, not scripts for attack.
Major section
Overview: Software Sits Between Everything (continued)
The One-Minute View Name the path State which interface, action, parser, or dependency is affected. "The dashboard has vulnerabilities" is not a finding.
- A fix is not done until retested Close a finding only after retest evidence shows it is fixed, or accept it with a clear exception.
- Beginner Examples "Passed a vulnerability scan" is not evidence of a safe path; the review still needs the affected path and control checked.
- Validating input is not the same as encoding output; both can be needed for the same field.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest
Software vulnerability review starts by naming the path under review, which in IoT may cross a device interface, gateway service, broker, dashboard, mobile app, update service, database, or cloud API.
- The workflow turns each finding into a decision a reviewer can repeat and audit.
- Common Vulnerability Classes Classes are patterns that help reviewers ask better questions.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Validation rules, bounded parser, output-encoding records, rejection logs.
- Scope fixes the authorized component, data, and test boundary; safe confirmation establishes the observed behavior without unnecessary harm.
- Classification names the failed control, prioritization accounts for exposure and consequence, and remediation changes the responsible boundary.
- Bounds checks, safe libraries, fuzz-test evidence, crash handling.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Retesting must exercise the original path and related denied case before the owner records evidence and a future trigger.
- They often overlap; record each weak control separately so each fix can be tested separately.
- Native parser with no fuzzing or bounds evidence.
- Inventory exists but no owner reviews changes.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Error-path review, log redaction, safe-failure tests.
- The class list becomes actionable at the point where untrusted data changes meaning.
- Receive identifies the source and channel; validation constrains type, size, range, and structure; parsing turns the bounded representation into data.
- The same boundary rule applies before data reaches SQL or XML processors.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Authentication names the actor; authorization decides whether that actor may take the action.
- This ordered boundary explains why validation, authorization, and encoding are complementary controls rather than interchangeable labels.
- Input Handling: Validation Is Not Encoding Input handling protects the point where untrusted data becomes application state, database content, rendered output, device command parameters, or configuration.
- Worked Review A gateway dashboard accepts device names, shows telemetry, lets operators change sampling intervals, and uses several protocol libraries.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
SQL injection is a query-construction failure: accepted text is allowed to change the database instruction instead of remaining a value.
- The key distinction: validation decides whether input is acceptable for a purpose, while encoding prevents accepted data from being interpreted as a different kind of instruction in a later context.
- In a browser-facing IoT dashboard, the HTML-output version of that failure is cross-site scripting (XSS) or HTML code injection: attacker-controlled text is rendered as markup or script instead of inert content.
- Reopen after any rendering, device-command, role-policy, parser, or dependency change.".
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
The review should name the output context, escape or sanitize for that context, retest the rendered page, and keep enough evidence to prove the value cannot become executable HTML.
- XML injection is a structure-construction failure: accepted text is allowed to create or alter XML elements, attributes, or parser behavior.
- A defensive review should ask for parameterized queries or equivalent prepared statements, context-aware XML construction, parser limits, rejected malformed-input evidence, and action-level authorization for any database or configuration change.
- A weak review says "the dashboard passed a vulnerability scan." A stronger review separates the finding types.
Major section
Practitioner: Classify, Map Controls, Prioritize, Retest (continued)
Input and authorization Device names are validated and encoded for HTML output; rejected values are logged without storing unsafe content; sampling-interval changes require an explicit management permission, and denied actions are audited.
- Dependency evidence The dashboard and gateway libraries have an inventory; advisory review identifies which components handle exposed input; updated components are retested against dashboard and gateway paths.
- Scoped decision "Accepted for this release after encoding, action authorization, dependency review, and retest logs were checked.
- If you can classify findings, separate validation from encoding, and check authorization at actions, you can stop here.
Major section
Under the Hood: Memory Safety, Supply Chain, and Secure SDLC
The deeper layer covers the classes that need more than a single control check: memory safety in native code, how injection and deserialization arise, supply-chain exposure, and the development process that keeps findings from recurring.
- Memory Safety Firmware and native services written in languages without automatic bounds checking must handle buffers, object lifetimes, and parser states carefully.
- The defensive review focuses on boundary checks, use of safe or hardened libraries, evidence of fuzz testing on input parsers, crash handling, and update readiness, rather than on attack mechanics.
- Prioritizing by Context A severity label alone is not enough.
Major section
Under the Hood: Memory Safety, Supply Chain, and Secure SDLC (continued)
Where the platform allows, memory-safe languages and compiler mitigations reduce the size of this class.
- The defense is context-aware output encoding or parameterized handling at the boundary where the interpretation occurs; input validation alone does not prevent it, because validated data can still be misinterpreted downstream.
- Insecure deserialization is a related parser-trust failure: software reconstructs objects or state from structured input and trusts that input too much.
- Updating a dependency is not complete until the path that uses it is retested, because the update can change behavior.
Major section
Summary
A software finding is reviewable only when it names the affected path, the security property, and the weak control, and is closed after retest.
- Common classes are input handling, authorization, memory safety, dependency, configuration, and error handling, and they often overlap.
- Injection and insecure deserialization are input-trust failures; dependency findings need reachability and advisory evidence, not just presence.
- Prioritize by system context, and build review, testing, and retest into the development lifecycle so fixes hold across releases.
Deck summary
Key takeaways
The support worker sees a bad screen; the software owner must find where untrusted input became trusted state and what property was lost.
- A weak parser, an unsafe input path, a missing authorization check, a vulnerable dependency, or an unclear remediation process can expose data or change device behavior.
- This map is the chapter's running discipline: every broad vulnerability label must become a specific path, control, and observed result.
- A vulnerability class is a category of leak: a cracked joint is an input-handling flaw, an unlocked valve is an authorization flaw, and an old corroded pipe is a vulnerable dependency.
Retrieval practice
Recall check 1 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q1What makes a software vulnerability finding reviewable in an IoT data system?
Show answer
Answer: A A finding is actionable when it is specific, tied to a control, and verified by retest, not a broad statement.
Retrieval practice
Recall check 2 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q2A dashboard stores user-provided device names and later renders them in an operator page. The review shows validation on input but no output encoding for the HTML context. What is the best defensive finding?
Show answer
Answer: B The finding should name the output context, the missing control, and the retest path.
Retrieval practice
Recall check 3 of 3
Shield Shelly says: answer from memory, then check your reasoning.
Q3A dependency scanner flags a vulnerable library in a gateway build. The library is compiled into the image but is never called by any reachable code path. How should this affect the finding?
Show answer
Answer: A Presence still matters and should be tracked, but reachability and exposure drive priority.
Print reference
Answers
Answer key.
- A · A finding is actionable when it is specific, tied to a control, and verified by retest, not a broad statement.
- B · The finding should name the output context, the missing control, and the retest path.
- A · Presence still matters and should be tracked, but reachability and exposure drive priority.