# Field Device and Code Security Baseline

# Field Device and Code Security Baseline

*Adapted from GitLab's Product Security, Vulnerability Management and Secure Coding pages, for NFE's field hardware and software.*

What NFE deploys at customer sites (meters, hybrid inverters, OpenEMS on Raspberry Pi, the inverter monitor) controls people's power. A compromise there is an **S1**.

## Baseline for every field device (before it leaves for a site)

- [ ] **Default passwords changed** on the inverter, meter, router and Pi (e.g. OpenEMS `admin/admin`, the Pi's default user). Credentials stored in the shared vault.
- [ ] **SSH:** key-based login only; password login and root login disabled.
- [ ] **No direct internet exposure:** no port forwarding to the Pi, OpenEMS UI or Modbus. Remote access only through a VPN or tunnel (Tailscale/WireGuard).
- [ ] **Modbus/TCP and RS-485 stay local.** Modbus has no authentication or encryption; some inverters accept write commands with no password. Restrict writes to the controller that needs them.
- [ ] **Updates:** OS security updates enabled (`unattended-upgrades` on Raspberry Pi OS). Firmware versions recorded.
- [ ] **Notification/alert endpoints** bind to localhost or require a token. See the [inverter-monitor hardening ADR](https://bookstack.nearlyfreeenergy.com/books/product/page/inverter-monitor-notifications-hardening-tuning-adr-012).
- [ ] Device recorded in the asset inventory (site, serial, firmware, who has access).

## Code we write

- No secrets in code or repositories. Use environment files kept out of version control, or a secret store. Scan repos with `gitleaks` before pushing (borrowed from GitLab's "gitleaks on your laptop").
- Review dependencies before adding them, and keep them updated.
- Peer-review changes that touch device control, payments or customer data.

## Vulnerabilities

1. Anyone who finds a weakness (in our code, a device, a vendor product) reports it like an incident; see [Reporting a Security Incident](https://bookstack.nearlyfreeenergy.com/books/security/page/reporting-a-security-incident).
2. The tech lead sets a severity with the [severity matrix](https://bookstack.nearlyfreeenergy.com/books/security/page/security-incident-severity-matrix) and creates a Plane task.
3. Target fix times: **S1 within 24–72 h, S2 within 2 weeks, S3 within 2 months, S4 best effort**. Vendor issues are tracked until the vendor ships a fix, with workarounds (isolation, disabling a feature) in the meantime.

## Related pages

- [Running OpenEMS Edge on a Raspberry PI](https://bookstack.nearlyfreeenergy.com/books/product/page/running-openems-edge-on-a-raspberry-pi)
- [Metering protocols: DLMS/COSEM, OBIS, Modbus, MQTT](https://bookstack.nearlyfreeenergy.com/books/product/page/metering-protocols-dlmscosem-obis-modbus-mqtt-and-nfe-chint-register-map)