What to protect? - and concrete developer actions

Cyber security is a very complex subject - filled with heavy math, but also with a lot of compliance and regulations. Before opening the latter - sometimes boring box - let's take a look at what we want to protect. I am using a lot of terms here. Many of these are - to a degree - explained in a table at the bottom of this page.

• Protect data in transit
  • Use TLS 1.3 or DTLS with AEAD ciphers and ECDHE for forward secrecy.
  • Prefer mTLS for device authentication or use unique per-device tokens/certs.
  • Use vetted libraries (mbedTLS, wolfSSL, BearSSL) and offload crypto to hardware where available.
  • CI tests: reject weak ciphers, verify handshake behavior, test MITM and downgrade attempts.
• Protect data at rest
  • Use authenticated encryption (AES-GCM, ChaCha20-Poly1305) for confidentiality and integrity.
  • Do not rely on CRCs for security; use MACs/AEAD for tamper detection.
  • Store keys in HW-backed keystore/secure element or protected flash with MPU/TrustZone.
  • Tests: tampered blobs must fail verification; firmware dumps must not expose plaintext secrets.
• Protect boot-phase
  • Establish a hardware root-of-trust and verified boot chain (ROM, signed bootloader, signed app).
  • Implement anti-rollback (monotonic counter or version checks) and safe recovery paths.
  • Lock or fuse debug/boot configuration in production as appropriate.
  • Tests: device must refuse unsigned or downgraded images; secure-boot keys protected.
• Protect source code
  • Enforce SCM access control, branch protection, mandatory code review and code-owner rules.
  • Integrate SAST, secure-coding standards (MISRA/CERT), and pre-commit hooks into CI.
  • Remove secrets from repo; use secret managers and secret-scanning in CI.
  • Tests: PRs blocked until high-severity SAST issues fixed; no hardcoded secrets.
• Protect binaries and third-party components
  • Maintain SBOM for all components and use automated dependency/CVE scanning.
  • Pin dependency versions, maintain an approved-component list, and define patch policies.
  • Tests: CI blocks builds with unpatched critical CVEs unless an approved exception exists.
• Protect firmware update mechanism (OTA)
  • Require signed images, authenticated update servers, encrypted transport, and anti-rollback checks.
  • Design staged rollouts and recovery for failed updates.
• Protect device identity & authentication
  • Provision unique per-device keys/certs securely; use hardware-backed identity when possible.
  • Support key rotation and revocation (short-lived certs or token renewal).
• Protect debug & manufacturing processes
  • Secure manufacturing provisioning, protect factory keys, and require explicit factory unlock for debug.
• Protect CI/CD & build system - mainly against insiders mistakes or bad will
  • Use signed and reproducible builds, manage pipeline secrets, and produce build provenance and SBOM.
• Protect logging, telemetry and privacy
  • Sanitize logs, avoid PII and secrets, encrypt telemetry, and authenticate telemetry channels.
• Manage vulnerability & incident response
  • Document disclosure process, patch management SLAs, orchestration for fleet updates, and incident playbooks.
• Deal with physical security and tamper resistance (as relevant)
  • Consider tamper sensors, secure enclosures, potting, and side-channel mitigations where risk justifies cost.

Which processes does the above lead to?

Testing & verification pipeline:

• Static analysis (SAST) and secure-coding checks in CI.
• Dependency/CVE scanning and SBOM generation.
• Unit/integration tests for crypto, auth, error handling, and OTA flows.
• Fuzzing of parsers and protocol stacks.
• Penetration testing (network and physical where relevant).
• Hardware tests: RNG health, key extraction resistance, JTAG/debug resistance.

Acceptance criteria examples (testable):

• All sensitive communications use TLS1.3/DTLS with AEAD and forward secrecy (CI/integration test).
• Device refuses unsigned or downgraded firmware (end-to-end test).
• No secrets or credentials in repo or build artifacts (secret-scan in CI).
• All third-party components have SBOM and no critical unpatched CVEs per policy (CI).
• Device identity keys are stored in HW-backed keystore or verified inaccessible (hardware test).
• RNG/ TRNG passes self-test at boot (hardware test).
• Debug interfaces are disabled or require explicit factory unlock for production units (factory test).

Prioritization (MVP / Phase 2 / Long-term):

• Minimal Viable Product (must have before shipping)
  • Signed firmware & secure boot.
  • TLS for sensitive comms, basic key management, unique device identity, secrets not in repos.
  • CI gating for SAST and dependency CVE checks.
  • OTA over authenticated encrypted channel.
• Later improvements
  • mTLS, short-lived certs & automated renewal, hardware-backed identity for all SKUs.
  • SBOM + automated patch deployment & rollback orchestration.
  • Hardened production builds (fuse JTAG, lock bootloader).
• Long-term (advanced)
  • Remote attestation, supply-chain provenance, continuous behavioral monitoring, tamper/side-channel protections.

Common pitfalls (summary):

• Treating CRC as security integrity — use cryptographic MACs/AEAD instead.
• Hardcoding credentials, keys, or secrets in source or firmware.
• Allowing downgrade or unsigned update paths.
• Leaving debug enabled on production units.
• Blindly trusting third-party libs without SBOM and update plan.
• No plan for CVE tracking, patching, or incident response.

Developer checklist:

• Unique device identity provisioned at manufacture/provisioning
• Keys stored in secure element or protected area; firmware cannot reveal them
• Secure boot chain enabled; bootloader & firmware signed
• OTA updates signed, integrity-checked and rollback-protected
• All sensitive comms use TLS1.3/DTLS with AEAD + ECDHE
• No hardcoded secrets in repo or artifacts (secret-scan passed)
• SAST and dependency CVE scan pass in CI (blocking for critical)
• Debug/JTAG locked for production units or require explicit factory unlock
• SBOM generated for each release and CVE policy applied
• RNG/TRNG health check on boot
• Logging sanitized (no PII/keys) and telemetry encrypted/authenticated
• Incident response & patch plan documented

Terms and acronyms used above

Codebase processes

Many of the above "protect"-actions can be implemented like "normal" features - e.g., the use of signed certificates and various keys in protocol handshakes. Some processes, however, are embedded in the daily work and are meant to protect the codebase. These are what we focus on now.

The figure below shows most of the processes an embedded developer may be involved with, when it comes to protecting the codebase

Vulnerabilities

A vulnerability is an issue in your product that may be exploited by hackers - or can be triggered accidentally by normal use. Traditionally, in medical and transportation, "safety" has been the major (only) considered risk to users. However, these days all sectors need to (also) consider security. There are many different kind of vulnerabilities:

• Your product may become unusable. This is DOS - Denial of Service.
• Your product may be able to do unwanted things. Sometimes your product does not seem affected, but it may be used in a "BOT" attack on other products or infrastructure.
• Your product may work completely as intended - but it may be possible to use it to get private information about users. This is mainly considered a risk in the EU - regulated by the GDPR - but if we talk about e.g., leaked credit-card information, it will be a problem everywhere.

Vulnerabilities are not in the center column in the figure above, because dealing with these often require a lot of work from QA. marketing, sales and sometimes top-management. "Vulnerability Disclosure" is about informing users about the issue - should they put in on a shelf until there is a patch?, are there workarounds?, when will there be a patch? - if ever, and so on. "Vulnerability Reporting" is targeted authorities - incl. updating the various vulnerability databases, in case someone uses your product in theirs. The term "CVE" means Common Vulnerabilities and Exposures. This relates to databases that register these issues.

Weaknesses

Examples of Weaknesses is e.g., "Buffer overflow", "Memory Leakage", "Null-pointer assignment" etc. This is classical problems that most of us have met in our carrier. There are more or less advanced tools that can scan your software for these kinds of errors. This is not a test in the target product, but a scan of the source code on a PC. This is called "Static Code Analysis".

Secure Coding Standards

For most software developers the "Coding" phase in the above figure is where we want to be. Also here we see compliance demands. Many organizations require coding guidelines, normally inspired by one of the below organisations:

• OWASP
  Open Worldwide Application Security Project.
  It is relevant to understand that the "W" in OWASP used to stand for "Web". As all other standards organisations, OWASP is expanding its reign. They have excellent rules, but much is related to user-interaction - like sql-injection - and Client-Server scenarios. Also a unix-like environment is often assumed. So not your average low-level embedded controller. However, since I am also interested in web-technology, I find it very interesting.
• SEI CERT
  CERT = Computer Emergency Response Team, but SEI CERT is guidelines from the Software Engineering Institute at Carnegie Mellon University.
  You will see that this is more guidelines than rules - and they often target a system with an OS (also RTOS) with sockets and files. SEI CERT was created for cyber security - but also safety. Several SEI CERT guidelines only have relevance in an environment with a filesystem, sockets ect.
• MISRA
  Motor Industry Software Reliability Association.
  Contrary to the two other organizations, MISRA was originally defined to be about safety. However - they also want to grow. MISRA has been heavily used in automotive - but also medical. Where the other two standards are mostly guidelines, MISRA has rules that can be "must (not)" or "should". MISRA is basically designed for a safe and secure setting (e.g., an Engine Control Unit), where programmers can make bad mistakes. MISRA comes from a world where small ECUs run a main program with a number of interrupts. A keyword here is "deterministic".

The right-side menu has links to the above three organizations. Note that while CERT and OWASP are easy to browse, MISRA wants money for their document. OWASP has an interesting Top-10 based on user input:

I recently participated in a training program from Secure Code Warriers - with all the above guidelines and rules. It was surprisingly interactive and educational.

Standards and Requirements

I asked ChapGPT to provide an overview of the involved standards - and what they enforce. The below output (except from my remarks in first column) was the response. I am not sure it's much help...