Hardening Developer Machines with OWASP SPVS
In my previous post, we took care of identity, so who can have access. Today we enforce the devices on which permitted people can work on a project.
The second subcategory of the OWASP SPVS is V1.2 Hardening User Machines.
Many developers don't care about local machine security because they think a properly enforced repository is enough. This is a dangerous myth. If a developer's computer is compromised or stolen, the attacker gains access to the codebase, SSH keys, and internal documentation, etc.
Let’s dive into the OWASP SPVS requirements for securing the developer's workstation.
Level 1: Foundational
The goal here is to enforce basic protection required in every project. We want to ensure that every device cannot be easily exploited if lost or attacked by common malware.
V1.2.1 & V1.2.2 Endpoint Protection and Updates
Endpoint Protection is the primary defense for a device against ransomware and trojans. This is critical, especially for developers who constantly download third-party libraries that could contain malicious scripts.
Implementation Best Practices
Configure Endpoint Protection: Enable built-it EPP like Microsoft Defender or install third-party protection like ESET Endpoint Security. Ensure that all services are running and configured correctly.
Automation: Configure your EPP to perform scheduled scans and automatic signature updates. For Microsoft Defender, you can use Group Policy to configure scheduled updates.
Warning: An antivirus with outdated signatures cannot stop modern polymorphic malware. Be updated. Be secure.
V1.2.3 Full Disk Encryption (FDE)
Laptops are portable, so they can be stolen easily. Without FDE, an attacker can boot a live OS from a USB drive and easily read all data, or plug the hard drive into another machine and bypass your OS password to read your source code, documentation files, trade secrets, and more.
Implementation Best Practices
- Standardize Tools: Configure full disk encryption like BitLocker or FileVault on all machines. I recommend enforcing it with MDM to make sure you don't forget to enable it on new machines. Always buy devices equipped with a TPM module to protect keys in it.
- Recovery Keys: Generate a recovery key for each machine and store it securely. If you use Microsoft Entra ID, you can store and recover BitLocker recovery keys using it. Microsoft Entra ID: BitLocker recovery process
V1.2.4 Patch Management
Unpatched operating systems and apps are goldmines for exploits. V1.2.4 requires a systematic way to ensure updates are applied on time.
Implementation Best Practices
- Enforce Deadlines: Use MDM policies to give users a specified time, e.g., 5 days, to install system updates. If the user doesn't perform it after the deadline, the update starts automatically. For Microsoft Intune, update ring policies to enforce the deadline: Update rings policy settings.
- Third-Party Patching: Don't just patch the OS. All other software should be patched too, especially those which has access to your sensitive data and source code, like web browsers and IDEs.
Level 2: Standard
There are no new requirements for Level 2; the requirements from Level 1 are sufficient.
Level 3: Advanced
At the highest level, we move beyond "standard" tools into the professional system hardening and proactive physical security.
V1.2.5 Automated Inactivity Lock
A laptop left open in a coworking office is a massive risk. An attacker can perform manual actions or plug in a "USB Rubber Ducky", a malicious USB that pretends to be an HID device (operating systems have fewer restrictions for HID devices) and execute advanced actions in seconds.
Implementation Best Practices
- Strict Timeouts: Enforce a maximum inactivity period before the screen locks. For example, for Microsoft Intune, go to
Devices->Configuration->Create->New Policy. Then set a platform, profile, and name. Then search for InteractiveLogon_MachineInactivityLimit and set its value to the desired number of seconds, e.g., 300 seconds = 5 minutes. - Train your employees Train your team to always take a device with them, when that is not possible, lock the device, and before login, check if there are some unknown devices in the USB ports.
- Use biometrics: Use biometrics to unlock the device. It's more convenient, so developers don't want to use the mouse jigglers to prevent device lock.
V1.2.6 OS Hardening via CIS Benchmarks
The Center for Internet Security (CIS) provides the requirements for system hardening and benchmarks to check if the workstation is compliant with them. These benchmarks contain hundreds of configuration settings that minimize the attack surface of an OS. CIS SecureSuite membership provides access to CIS Build Kits. These are prepared packs of compliant settings for different platforms like Microsoft Intune. If you load settings into your system, then you can use CIS-CAT Pro to assess your configuration.
Checklist for OWASP SPVS V1.2 Hardening User Machines
Level 1 (Foundational)
- V1.2.1 Endpoint Protection is active on all workstations
- V1.2.2 Endpoint Protection signatures are updated automatically (e.g., daily)
- V1.2.3 Full Disk Encryption (BitLocker/FileVault) is enabled
- V1.2.4 OS updates are scheduled and applied automatically
Level 3 (Advanced)
- V1.2.5 Workstations lock automatically after inactivity, e.g., 5 minutes
- V1.2.6 OS configuration has been enforced with CIS Benchmarks
What’s Next?
We have already secured the identity of the developer and the machine they use. Now it's time to take care of the security risks and requirements. In the next post, we will explore the next subcategory, V1.3: Security Requirements and Risk Assessment, where we’ll discuss how to document the pipeline and establish the security policy.