Software supply chain attacks do not always begin with a vulnerable library.
Sometimes, they begin with a person.
The Rust Project has warned about an ongoing social engineering campaign targeting Rust team members and maintainers of popular crates. Attackers are reportedly using convincing job, project, and contract opportunities to establish contact with developers and then attempting to compromise their devices or accounts.
The objective is particularly concerning for the open source ecosystem.
If attackers gain control of a trusted developer account, they may potentially use that access to publish malicious software that downstream organizations and applications trust.
The Rust Project says the current campaign is targeting prominent members of the Rust community and popular crate owners. The campaign involves video calls and attempts to convince victims to install software or execute commands on their systems.
SecurityWeek reports that the techniques resemble activity previously associated with North Korean threat actors, although the current campaign has not been definitively attributed to a specific actor.
How the Attack Works
The campaign demonstrates how modern social engineering can combine human trust, developer privileges, and software supply chain access.
Attackers reportedly approach developers with seemingly legitimate professional opportunities.
The interaction may begin with:
• A job opportunity
• A software development project
• A consulting opportunity
• A contract proposal
• A technical collaboration
The attacker then attempts to move the target into a video call.
During the call, the victim may be told that their computer is missing an audio or video component and needs additional software.
In other reported scenarios, victims may be encouraged to execute a command that has been placed on their clipboard.
The important security lesson is that the attack does not necessarily begin with an obviously malicious email or traditional phishing page.
It begins with a conversation.
Fake Companies Make Social Engineering More Convincing
One particularly concerning element is the effort attackers are reportedly making to establish credibility before contacting developers.
The Rust Project says attackers have created new company profiles, including LinkedIn presences, that appear legitimate enough to pass a quick visual inspection.
This reflects a broader change in social engineering.
Attackers increasingly understand that people investigate suspicious contacts before engaging with them.
Instead of relying only on poorly written messages or obviously fake websites, threat actors can create an entire professional identity around a campaign.
That identity can include:
• Company websites
• LinkedIn profiles
• Employee profiles
• Job descriptions
• Professional email accounts
• Meeting invitations
• Technical discussions
• Business registration information
The result can be a highly credible pretext designed to lower the target’s suspicion.
Why Rust Crate Maintainers Are Valuable Targets
Open source developers can have privileges that extend far beyond their individual computers.
A maintainer of a popular package may control:
• Source code repositories
• Package publishing accounts
• CI/CD pipelines
• Release automation
• Signing credentials
• API tokens
• Cloud environments
• Build systems
• Dependency metadata
A compromised developer account can therefore become a supply chain entry point.
Instead of attacking hundreds of organizations individually, an attacker may attempt to compromise one trusted software maintainer and use the software distribution process to reach downstream users.
This makes developer identities valuable security assets.
The Supply Chain Connection
The Rust ecosystem uses crates as reusable software components.
Organizations can incorporate these packages into applications, services, development tools, and production environments.
This creates a chain of trust:
Developer → Repository → Build Pipeline → Package Registry → Application → Enterprise Environment
If attackers compromise one stage, the effects can potentially move downstream.
This is why software supply chain security cannot focus exclusively on vulnerability scanning.
Organizations also need to protect the people and systems responsible for producing software.
The Developer Account Is Part of the Attack Surface
Traditional security programs often focus heavily on servers, endpoints, networks, and cloud infrastructure.
Developer accounts deserve the same level of attention.
A developer with publishing or repository privileges can potentially influence software that is consumed by other teams and organizations.
Organizations should therefore treat developer identities as privileged accounts.
Important controls include:
• Strong multi factor authentication
• Phishing resistant authentication where possible
• Least privilege access
• Short lived credentials
• Secure secrets management
• Device security monitoring
• Repository access controls
• Package publishing restrictions
• Detailed audit logging
• Regular access reviews
Security teams should also monitor developer accounts for unusual activity such as unexpected logins, changes in publishing permissions, unfamiliar devices, or unusual package releases.
Why Video Calls Can Become an Attack Vector
Video conferencing is normally viewed as a trusted business communication channel.
That trust can be exploited.
A video call can provide attackers with a more convincing environment for social engineering because the interaction feels more personal than a traditional phishing email.
During a call, an attacker can:
• Build rapport with the target
• Create a sense of urgency
• Present technical explanations
• Share files or links
• Request software installation
• Encourage command execution
• Direct the victim toward a specific workflow
The Rust Project specifically recommends that developers be cautious with unsolicited approaches and conduct calls with new contacts through platforms they trust, ideally using a meeting platform they initiate themselves.
This is an important defensive practice for organizations beyond the Rust ecosystem.
The Clipboard Can Become a Security Boundary
Another important lesson is the risk associated with commands placed into a clipboard.
Developers routinely copy and paste commands because software development involves working with:
• Terminal commands
• Package installation instructions
• Git commands
• Configuration files
• Cloud CLI commands
• Deployment scripts
• Debugging instructions
That convenience can become dangerous when the origin of the command is not independently verified.
A command copied from a message, website, chat, or video call should not automatically be trusted.
Organizations should train developers to verify commands before execution, particularly when they involve:
• Administrative privileges
• Authentication credentials
• Security configuration
• System downloads
• Remote connections
• Package installation
• Cloud infrastructure
Developer Security Training Needs to Evolve
Traditional security awareness training often focuses on email phishing.
That is no longer enough for modern engineering organizations.
Developers should also be trained to identify:
• Fake technical recruiters
• Fraudulent contractors
• Fake open source contributors
• Malicious project invitations
• Suspicious video meetings
• Fake software installation requests
• Clipboard based command execution
• Credential harvesting attempts
• Fake GitHub or package registry notifications
• Malicious dependency recommendations
The goal should not be to discourage developers from collaborating.
The goal is to establish a verification process before trust is granted.
Protecting the Software Supply Chain
Organizations that depend on open source software should assume that both technical vulnerabilities and identity compromises are possible.
A mature software supply chain security program should include multiple layers.
1. Protect Developer Identities
Developer accounts with repository or package publishing permissions should receive privileged access protections.
2. Enforce Strong Authentication
MFA should be mandatory for repositories, package registries, cloud platforms, and other critical developer services.
3. Reduce Long Lived Credentials
Long lived tokens create additional opportunities for credential theft.
Where supported, organizations should prefer short lived credentials and trusted publishing mechanisms.
4. Monitor Package Releases
Security teams should monitor unexpected package versions, unusual publishing activity, maintainer changes, and suspicious release patterns.
5. Secure CI/CD Pipelines
Build and deployment systems should use tightly scoped identities and protected workflows.
6. Implement Software Composition Analysis
Organizations should maintain visibility into open source dependencies and continuously evaluate them for known vulnerabilities and suspicious changes.
7. Protect Secrets
API keys, cloud credentials, signing keys, and repository tokens should not be stored in source code or developer environments without appropriate protection.
8. Review Privileged Access
Access to repositories, package registries, build systems, and cloud environments should be reviewed regularly.
9. Maintain Incident Response Procedures
Organizations should have predefined procedures for responding to compromised developer accounts and potentially malicious package releases.
10. Establish Package Verification Processes
Critical software dependencies should be evaluated based on provenance, maintainership, release history, security advisories, and organizational requirements.
Rust Has Faced Previous Crate Security Challenges
The latest campaign comes against a broader background of security challenges affecting package ecosystems.
The Rust Project has previously dealt with malicious crates, typosquatting, credential related incidents, and phishing campaigns.
For example, the Rust security team previously warned about malicious crates designed to impersonate popular packages. The project has also published guidance and security advisories concerning suspicious packages and account security.
This reinforces an important point:
Open source security is not a one time activity.
It requires continuous monitoring of identities, dependencies, repositories, package releases, and development environments.
Industries That Need to Pay Attention
The risks described in the Rust campaign extend well beyond software companies.
Financial Services and Banking
Financial institutions rely heavily on third party software, open source libraries, cloud platforms, APIs, and internal development teams.
COE Security can help financial organizations evaluate software supply chain risks, secure developer environments, perform application and API penetration testing, assess CI/CD security, and strengthen identity and access controls.
Healthcare and Life Sciences
Healthcare organizations increasingly depend on software platforms, cloud applications, integrations, and open source technologies.
A compromised software dependency could introduce risk into systems handling sensitive information.
COE Security can help healthcare organizations assess application security, software dependencies, cloud environments, access controls, and compliance requirements.
Retail and E-commerce
Retail businesses use large software ecosystems across websites, mobile applications, payment systems, customer platforms, and cloud services.
COE Security can help retailers assess application security, API security, third party dependencies, cloud infrastructure, and software development pipelines.
Manufacturing and Industrial Organizations
Manufacturers increasingly depend on connected applications, enterprise software, cloud systems, supplier platforms, and development environments.
COE Security can help manufacturers assess software supply chain risks, connected applications, cloud environments, network security, and identity controls.
Government and Public Sector
Government organizations depend on complex software ecosystems and third party technology providers.
COE Security can help government organizations strengthen application security, software supply chain security, identity management, cloud security, vulnerability management, and compliance programs.
Technology and SaaS Companies
Technology organizations are particularly exposed because their products may incorporate large numbers of open source components and may distribute software to thousands or millions of customers.
COE Security can help technology and SaaS companies conduct secure software development assessments, dependency reviews, source code assessments, API testing, cloud security assessments, penetration testing, and supply chain security reviews.
What Organizations Should Do Now
Organizations should not wait for a developer account to be compromised before strengthening their controls.
Security teams can begin with several practical actions:
• Identify developers with package publishing privileges
• Review repository and package registry permissions
• Enforce MFA across development platforms
• Prefer phishing resistant authentication for privileged accounts
• Audit active API tokens and credentials
• Monitor unusual developer login activity
• Review recent package releases
• Implement dependency scanning and SCA
• Monitor changes to critical dependencies
• Secure CI/CD credentials
• Protect source code repositories
• Conduct developer focused security awareness training
• Establish procedures for compromised maintainer accounts
• Test incident response plans against software supply chain scenarios
The Rust campaign demonstrates how a convincing professional interaction can become the first stage of a much larger software supply chain attack.
The attack does not need to begin with a vulnerable server.
It can begin with a developer receiving a credible looking opportunity, joining a video call, installing unexpected software, or executing an unverified command.
Once a privileged developer account is compromised, the potential impact can extend beyond one individual to repositories, package registries, build pipelines, applications, and downstream organizations.
For businesses that depend on open source software, developer security must therefore become part of the broader cybersecurity strategy.
Protecting the software supply chain requires more than vulnerability scanning.
It requires strong identity security, secure development practices, privileged access controls, continuous monitoring, dependency governance, developer awareness, and well tested incident response.
As software ecosystems become increasingly interconnected, protecting the people and processes behind trusted software is just as important as protecting the infrastructure that runs it.
About COE Security
COE Security partners with organizations in financial services, healthcare, retail, manufacturing, and government to secure AI-powered systems and ensure compliance.
Our offerings include:
• AI-enhanced threat detection and real-time monitoring
• Data governance aligned with GDPR, HIPAA, and PCI DSS
• Secure model validation to guard against adversarial attacks
• Customized training to embed AI security best practices
• Penetration Testing (Mobile, Web, AI, Product, IoT, Network & Cloud)
• Secure Software Development Consulting (SSDLC)
• Customized CyberSecurity Services
• Follow COE Security on LinkedIn for ongoing insights into safe, compliant AI adoption.
In addition, COE Security helps organizations strengthen software supply chain security through Secure Software Development Lifecycle implementation, Software Composition Analysis, dependency risk assessments, source code security reviews, developer environment assessments, CI/CD security assessments, repository security reviews, API security testing, cloud security assessments, vulnerability management, identity and access management reviews, and penetration testing.
For financial services and banking organizations, we help protect critical applications, development environments, APIs, cloud infrastructure, privileged developer accounts, and software dependencies while supporting cybersecurity and compliance requirements.
For healthcare and life sciences organizations, we help secure applications, third party integrations, cloud platforms, software dependencies, sensitive data environments, and development pipelines while supporting regulatory security requirements.
For retail and e-commerce organizations, we help assess web applications, APIs, payment environments, cloud infrastructure, external dependencies, and software development workflows to reduce supply chain and application security risks.
For manufacturing and industrial organizations, we help evaluate connected applications, enterprise software, cloud environments, supplier technology, development systems, and identity controls to strengthen the broader technology ecosystem.
For government and public sector organizations, we help strengthen software supply chain security, application security, cloud security, identity management, vulnerability management, monitoring, and compliance programs.
For technology and SaaS companies, we help secure source code repositories, package ecosystems, CI/CD pipelines, APIs, cloud environments, developer identities, and third party dependencies through security assessments, penetration testing, secure development consulting, and continuous security practices.
Our goal is to help organizations identify security gaps, protect critical digital assets, reduce software supply chain risk, strengthen cyber resilience, and maintain compliance across increasingly connected technology environments.
Follow COE Security on LinkedIn for ongoing insights into safe, compliant AI adoption, software security trends, emerging cyber threats, and practical cybersecurity strategies to help your organization stay updated and cyber safe.
Click to read our LinkedIn feature article