Safety Norms: Mobile, Desktop and Embedded Application Development

1Purpose, Scope and Safety Principles

These norms apply to anyone who designs, writes, tests, signs, releases or maintains software for phones, tablets, desktop computers and embedded controllers such as sensors, appliances, wearables, vehicle modules and industrial devices. Scope includes source code, build pipelines, firmware images, third-party libraries, test hardware, cloud services that support the product, and the data the product collects or stores.

Three principles guide every later section. First, design for the worst credible misuse rather than the happy path. Second, apply least privilege so that every component, account and tool receives only the access it needs. Third, fail to a safe state, meaning the software must degrade predictably when a sensor, network connection or power supply misbehaves. These principles are the reference point when a rule seems to conflict with a deadline.

• Mandatory: no release ships with a known critical security defect unless a documented risk acceptance has been approved by the product owner and the security reviewer.
• Mandatory: every embedded function that can move, heat, or energize hardware has a defined safe state recorded in the design file.
• Recommended: review the safe state of each function during design review, not only after a failure is reported.

2Roles, Competence and Accountability

A product owner accepts residual risk for each release. The technical lead owns architecture and secure design decisions. Developers own the correctness and security of their own changes. A security reviewer and a privacy reviewer examine designs that touch authentication, payments, location, health data or personal information. For embedded work, a hardware or electrical engineer reviews power, thermal and actuator designs. Test engineers own test plans and test rigs. A release manager controls signing keys and publication, and no single person should hold both the ability to approve a change and the ability to sign it for release.

Competence is demonstrated, not assumed. Engineers working on cryptography, firmware update mechanisms, safety-related functions, or products in regulated areas such as medical, automotive, aviation or industrial control need documented training and supervision appropriate to that area. Do not allow unqualified staff to flash devices connected to live systems, change safety interlocks, or handle production signing keys.

• Mandatory: assign a named owner to every repository, device model, test rig and signing key.
• Mandatory: keep a current list of people authorized for production access and remove access promptly when a role changes.
• Mandatory: require two-person review for changes to authentication, payment, location, health, or safety-critical code.
• Recommended: name a deputy for each signing and incident role so that work does not stop during absence.

3Course-Specific Hazards and Risk Assessment

Hazards in this field fall into four groups. Security hazards include insecure storage of credentials, injection flaws, unsigned updates, debug interfaces left enabled, and vulnerable third-party libraries. Privacy hazards include collecting location, contacts, microphone or health data without a clear need, retaining logs longer than required, and sharing data with analytics providers without disclosure. Physical hazards arise in embedded work: overheating batteries, actuators that move unexpectedly, high-voltage test benches, and firmware that drives motors or heaters beyond design limits. Reliability hazards include crashes, data loss, memory exhaustion, and failed updates that leave devices unusable.

Typical activities include writing code on workstations, running emulators and simulators, connecting prototypes to bench power supplies, testing on real phones with real accounts, reproducing customer bugs from logs, and flashing firmware through debug ports. Typical tools include development environments, compilers, package managers, debuggers, flashing utilities, code signing certificates and crash reporting services. Environments range from office benches to field trials and customer sites. Assess each hazard by likelihood and severity, rated low, medium or high, and record the result in the design file. Revisit the assessment when architecture, suppliers, intended users or operating environment change.

• Mandatory: score every hazard before feature freeze, not after launch.
• Mandatory: treat any test on a live customer account or real personal data as a high-risk activity that requires written approval.
• Mandatory: do not connect unverified power supplies or battery packs to prototypes without the hardware owner's sign-off.
• Recommended: keep a short hazard register for each product line and review it at every major milestone.

4Preventive Controls and Safe Work Practices

Preventive controls work best when built into the toolchain and review process rather than relied on from memory. Use version control for all code, configuration and build scripts, with protected main branches and mandatory peer review. Store secrets in an approved secrets manager, never in source files, screenshots, sample apps, logs or chat messages. Pin dependency versions, verify checksums, and maintain a software bill of materials so that a vulnerable component can be located quickly when an advisory is published.

Secure design practices include threat modeling for each new feature, validation of all input at trust boundaries, parameterized database queries, memory-safe languages where practical, and error handling that does not expose internal details to users. For embedded devices, require signed firmware, verified boot where the hardware supports it, rollback protection, and a tested recovery path. Explain these controls in plain terms in design documents so that reviewers can check them rather than assume them.

Authorized testing means testing only systems, devices and accounts that your organization owns or has written permission to test, within a defined scope and time window. Penetration tests, fuzzing, load tests and hardware fault injection must follow a written plan with stop conditions. Do not probe third-party services beyond their published terms. Run hardware tests with current-limited supplies, fused circuits, insulated tools and a second person present whenever mains voltage or high current is involved. Use synthetic or masked data for all testing unless the privacy reviewer has approved a specific exception.

• Mandatory: never commit credentials, keys, tokens or personal data to any repository.
• Mandatory: release builds come only from tagged commits produced by the approved build system.
• Mandatory: firmware and app updates must be cryptographically signed and verified on the device before installation.
• Mandatory: security testing that leaves the approved scope stops immediately and is reported to the security reviewer.
• Recommended: run static analysis and dependency scanning on every merge request.
• Recommended: release new functions behind feature flags to a small group before broad rollout.

5Equipment, Environment, Information and Protective Safeguards

Workstations and test devices need baseline protection: full disk encryption where the platform supports it, automatic screen locking, current operating system and tool patches, endpoint protection approved by the organization, and separate administrative accounts. Production signing keys belong in hardware security modules or managed key services with access logging. Shared test devices must be labeled, inventoried, and reset or wiped before reuse or disposal. Lost or stolen test hardware is reported as a security incident.

Privacy safeguards apply to test data as much as production data. Collect only the permissions and telemetry a feature needs, explain them to users in plain language, and provide a working way to withdraw consent. Data protection, consumer product, accessibility and app store requirements vary by jurisdiction and by market, so confirm them with qualified legal counsel and the platform publisher's current policies before release.

For embedded hardware, protective safeguards include enclosure ratings matched to the operating environment, fuses and current limits, thermal shutdown tested under load, and warning labels on hot or high-voltage parts. Bench technicians wear safety glasses when cutting leads or soldering, and use electrostatic discharge protection when handling exposed boards. Electrical, battery and wireless standards are product-specific and jurisdiction-dependent. Consult component datasheets, manufacturer instructions and the relevant certifying body before powering, modifying or certifying a design.

• Mandatory: no production or customer data on personal devices unless written organizational policy allows it and controls are in place.
• Mandatory: battery and high-voltage work is performed only by trained people using rated equipment.
• Recommended: keep a bench log that records equipment, firmware version, operator and any abnormal behavior.

6Incident Reporting, Emergency Response and Escalation

Report security incidents, suspected data exposure, safety-related defects, overheating, unexpected motion, and lost or stolen hardware immediately to the designated incident contact. Do not wait to confirm the cause before reporting. Near misses, such as a leaked token caught by a scanner or a build that nearly shipped with debug mode enabled, are reported in the same way because they reveal weaknesses in controls that should be corrected.

For physical hazards, first make the area safe. Use the device's emergency stop or disconnect power only if this can be done without exposing yourself to harm. Call local emergency services when there is injury, fire, smoke or any threat to life. Do not attempt rescue or repair of energized equipment without training. For suspected security breaches, isolate affected keys and accounts, preserve logs and evidence, and avoid deleting files that may be needed for analysis. Notification duties to customers, regulators or affected individuals depend on jurisdiction and contract terms. Legal counsel decides these, and the applicable timelines must be verified with the competent authority.

• Mandatory: revoke exposed credentials according to the incident runbook as soon as exposure is confirmed.
• Mandatory: a field update or recall decision for a safety defect is made by the product owner after safety and legal review.
• Mandatory: staff who discover an active hazard stop work in that area and notify the incident contact.
• Recommended: hold a blameless review after each significant incident and record corrective actions with named owners and completion checks.

7Records, Training, Inspection and Review

Keep records that allow someone to reconstruct what was built, tested, approved and released. Minimum records include design documents, risk assessments, code review approvals, test reports, signing and release logs, device inventories, training completions and incident reports. Retention periods depend on contract, sector and jurisdiction rules and must be set by the organization with legal advice.

Training should cover secure coding, privacy basics, the organization's incident process and hardware safety for anyone who handles prototypes. Refresh training when tools, platform rules or threats change. Inspect labs, build infrastructure and access lists on a scheduled basis, and track measures such as open critical findings, failed update attempts and overdue corrective actions. Use these results to revise these norms openly rather than granting silent exceptions.

• Mandatory: every released version can be traced to its source commit, build record, tester and approver.
• Mandatory: access lists for repositories, signing systems and test devices are reviewed on a scheduled basis.
• Recommended: run tabletop exercises for credential leaks, device recalls and failed firmware updates.

8Practical Checklist and Conclusion

Use the checklist before each release, device handover or major design change. It is a starting point for locally approved procedures and does not replace them, supervision or professional judgment.

Safe development is ongoing work. Teams that combine clear ownership, disciplined preventive controls, honest incident reporting and regular review are better placed to protect users, devices and bystanders. Verify all laws, standards, certification requirements and manufacturer instructions with the relevant authority or a qualified professional before relying on them.

Implementation checklist

• Confirm a named owner, reviewer and authorized signer for this release.
• Verify that the threat model and hazard assessment are current and reviewed.
• Scan the repository and build for secrets, personal data and vulnerable dependencies.
• Confirm signed builds and a verified update and rollback path on each target device.
• Check that all testing stayed within the written scope and authorization.
• Confirm privacy notices, permissions and data collection match the feature as built.
• Verify bench equipment is rated, labeled and operated by a trained person.
• Confirm incident contacts, credential revocation steps and recovery procedures are documented.
• Record test results, approvals and release traceability in the release file.
• Schedule the post-release review and assign owners for every corrective action.