Out-of-date or Vulnerable Developer Access Services

Severity: Critical

Likelihood: High (Developer environments are fast-moving and often lag behind in security controls)

General Guidance

Continuously audit and modernize developer access controls, ensuring least privilege, strong authentication, and timely removal of outdated tools, credentials, and permissions.

What is the concern?

Developer access often includes elevated privileges to repositories, CI/CD pipelines, cloud environments, and production systems. If access is outdated (e.g., former employees, stale credentials, old SSH keys) or vulnerable (e.g., weak authentication, exposed tokens), attackers can exploit it to inject malicious code, access sensitive data, or take control of critical systems.

Business Impact

Unauthorized access to source code and intellectual property
Insertion of malicious code or backdoors into applications
Compromise of CI/CD pipelines leading to supply chain attacks
Exposure of secrets (API keys, credentials, certificates)
Full infrastructure compromise via privileged developer accounts
Reputational damage and loss of customer trust

How can this risk be resolved?

Enforce least privilege access and role-based access controls (RBAC)
Require Multi-Factor Authentication (MFA) for all developer accounts
Regularly rotate and audit API keys, tokens, and SSH keys
Remove access for inactive users and departed employees immediately
Implement Privileged Access Management (PAM) solutions
Secure CI/CD pipelines with strong authentication and code signing
Monitor and log all developer activity across systems

KYND will flag a "Developer Access" instance as a risk when a known vulnerability exists in the version being used, or if the instance is visible externally when it shouldn't be. For these risks the advice is the following 2 mitigating steps:

1) Make sure the service is updated to the latest stable version (For OpenSSH the latest version can always be found here: https://www.openssh.com/releasenotes.html)

2) The use of firewalls and placing the port (or the whole host) behind a VPN configured to only allow authorised users to access it, and using an allow list/firewall rules to limit connectivity.

KYND performs an external, non-intrusive scan. These actions will also prevent the open port from being flagged in a KYND scan.

If these actions aren't possible, you should take alternative steps to mitigate the issue.

This could include adding extra layers of authentication, including MFA or PKI certificates to ensure that only authenticated users and services are able to connect.

If none of these are possible, or if you are using these services as honeypots, then these services should be entirely separated from the rest of your organisation's infrastructure, ensuring that there is no way an attacker could traverse from an attack on this service to gain access to sensitive data, services, networks or infrastructure.

Real-World Example

Uber Breach (2022): An attacker gained access using compromised credentials and MFA fatigue tactics, eventually obtaining privileged access to internal systems, including code repositories and administrative tools.
Codecov Supply Chain Attack (2021): Attackers modified a CI/CD script to exfiltrate sensitive environment variables and credentials from developer environments, impacting numerous downstream customers.
SolarWinds (2020): Compromise of the development and build environment allowed attackers to inject malicious code into software updates, affecting thousands of organizations globally.

Detection Opportunities

Monitoring for inactive or stale accounts still having access
Detection of logins from unusual locations or devices
Alerts on excessive permission use or privilege escalation events
Identification of hardcoded or exposed secrets in repositories
Unusual activity in CI/CD pipelines (e.g., unauthorized script changes)
Detection of new or unapproved SSH keys/tokens being added
Access attempts to critical systems outside normal developer workflows