Yocto Image Features: Avoid Shipping Debug Access in a Production Image

A development image is convenient because engineers can log in quickly and inspect the device. Reusing that image recipe for production can carry those conveniences into a product without anyone making an explicit access decision. Removing one visible debug setting is not enough unless the effective image configuration and the delivered authentication behavior are checked together.

This is a defensive release-review procedure for Yocto Project 5.0.12 Scarthgap images. It does not prescribe a universal login policy or claim that a particular device is secure. No image was built and no authentication test was executed for this article.

Write the intended access policy first

List the access paths the production product is intended to expose: network administration, physical console, service interface, and any factory-only route. For each, identify whether it should be disabled, available only after provisioning, or usable by a specified authenticated role. Keep recovery requirements visible so removing development access does not silently remove the only supported repair route.

Separate development, manufacturing, and field-service requirements. A factory may need temporary access to provision a device, but that does not automatically justify the same access on every shipped unit. Define the transition condition and the evidence that provisioning completed before the unit leaves that state.

Do not store actual credentials in the review worksheet. Record how credentials are provisioned and which policy should be enforced. The test plan can identify the credential class or role without copying private secrets into build logs or release notes.

Inspect the effective image features

The Yocto image-feature reference describes debug-tweaks and individual features affecting empty-password and root-login behavior. Inspect the effective IMAGE_FEATURES and EXTRA_IMAGE_FEATURES for the actual production image, including contributions from local configuration and inherited metadata.

Treat each relevant feature as a lead for inspection, not as a complete security verdict. A recipe may install a custom daemon configuration, a postprocessing step may modify accounts, or provisioning may change authentication state on first boot. Conversely, an installed SSH package does not by itself prove that remote root access is enabled.

Record where every production access setting originates. A local build override that disables a convenience feature may protect one engineer's image while leaving the automated release build unchanged. Put the durable policy in reviewed product metadata and verify the release configuration that will actually be used.

Review accounts and service configuration separately

The extrausers class reference describes image-level account and group changes. The same documentation cautions against hardcoded default passwords for production. Review account creation, locked states, privileges, and the provisioning path rather than assuming a single feature controls all of them.

Inspect the delivered service configuration as well as the account database. Authentication can be affected by both. Identify which recipe or image transformation owns each file, and check that a later step does not overwrite the reviewed version. Avoid placing passwords or their reusable hashes in examples, screenshots, or broadly accessible build artifacts.

For a legitimate maintenance route, document how it is enabled, authenticated, logged, and retired. The correct design depends on the product and threat model. The engineering review should make that design testable without declaring that an undocumented emergency account is acceptable merely because it helps during development.

Test refusals as well as successful access

A production-access test should include attempts expected to fail. On an authorized test device, verify that the disallowed role or credential condition is rejected through each relevant interface. Also verify the approved maintenance path, because a policy that blocks all access may fail the product's support requirements.

Use a device with the same image and provisioning state that customers receive. A board used for months in development can retain credentials, configuration, or enabled services that mask the release image's initial state. Record whether the test is before provisioning, immediately after provisioning, or after an update.

1. Build the production image from the recorded release configuration.
2. Inspect its effective image features, account setup and service configuration.
3. Boot an authorized test unit in the defined initial state.
4. Verify rejected empty-password or privileged access cases required by the policy.
5. Verify the approved access route and its expected privilege boundary.
6. Repeat after provisioning, reboot and a representative update path.

These are proposed checks. Do not perform them against unrelated systems or assume that a failed network connection proves authentication is secure. Determine whether the service was reachable, whether authentication occurred, and why access was refused.

Check the development-to-production transition

Keep the development image useful, but give it an unmistakable identity and delivery path. Review the artifact selection in flashing and release procedures so a factory operator cannot easily choose a development image under a production-looking filename. Hashes and release identifiers should connect the tested policy to the file actually installed.

Test the transition between image variants where the product supports it. Persistent configuration can survive a reflash or update. Decide whether that state should be retained, migrated, or reset, and verify the chosen behavior. Removing a development setting from a newly generated filesystem may not remove an already persisted copy on a device.

Make the release result precise

The handoff should state which access policy was tested, which image hash and provisioning state it covers, and which interfaces remain outside the test scope. Preserve failures and their fixes as regression cases. Avoid replacing this evidence with a statement that debug features were removed.

The goal is an explicit, repeatable boundary between engineering convenience and production access. A release is ready for its next security review when the effective metadata, delivered files, and observed access behavior agree with the product's documented policy, including the supported recovery path.