CICD Security and its Relation to GitHub, GitLab, and Jenkins
The Software Supply Chain (SSC) has become a prime target for attackers looking to compromise systems and undermine organizations. Social Engineering (SocE) tactics, specifically targeting software developers, have emerged as a significant area of concern within the Software Development Life Cycle (SDLC). Adversaries interact with developers at critical stages such as accessing repositories, incorporating code dependencies, and seeking approval for Pull Requests (PR) to introduce malicious code [1].
SocE Tactics Employed in SSC Attacks
Adversaries utilize a variety of SocE tactics to manipulate Software Engineers (SWEs) into delivering malicious software. These tactics include:
- Account Compromise: Stealing credentials for developers' platforms
- Device Compromise: Luring developers to install malware
- Malicious Pull Request: Posing as an open source contributor to add malicious code
- Malicious Dependency Watering Hole: Inadvertently adding malicious dependencies
- Malicious Code Snippet Watering Hole: Inadvertently adding malicious code from platforms like Stack Overflow
- Entering the Rank of Maintainers: Social engineering to become an open-source project maintainer
Manifestation in SDLC Steps
The SocE attacks are intricately linked to the different steps within the SDLC, from Source Code Development to Runtime Support and Updates. The paper systematically presents an overview of these manipulative strategies and assesses their impact on the security of the software supply chain.
Relation to Continuous Integration/Continuous Delivery (CI/CD)
Following the merge of code, the automated CI/CD process comes into play. This process involves recompiling or rebuilding the software and deploying the output into the company’s registry. Subsequent scripts retrieve these artifacts, facilitating deployment within the company’s computing clusters. This highlights the potential vulnerability introduced by human psychology within the CI/CD process.
SocE within the Scope of the SSC Landscape
The research identifies and delves deep into the nuanced interplay of social engineering within the SSC landscape. It coins the term 'DevPhish' to encapsulate the act of manipulating SWEs to introduce malicious code into the software. This novel term draws attention to the significant vulnerability introduced by human psychology within the realm of SSC.
Data Collection and Methodology
The study outlines its data collection and labeling methodology, emphasizing the importance of a systematic literature review (SLR) to select and evaluate relevant studies from academic papers, industry reports, and real-world incidents. The results show the classification of DevPhish techniques employed in SSC attacks into six categories.
Examples of DevPhish Attacks
The paper provides numerous real-world examples of DevPhish attacks, including incidents involving compromised accounts, malicious pull requests, and the compromise of official repositories.
Implications and Recommendations
The research emphasizes the need for community consensus on establishing robust auditing mechanisms to shield SSC from DevPhish attacks. It also underlines the importance of updating threat models and ensuring that the SSC community considers all possible attack surfaces, including human factors.
Conclusion
The paper concludes by highlighting the need for custom prevention and detection mechanisms tailored to the workflows of software developers and urges further exploration and research in this domain.
Overall, the paper provides valuable insights into the prevalent SocE tactics employed in SSC attacks, shedding light on the critical intersection between social engineering and the security of software supply chains.
The content has been condensed for the purpose of this blog post. For the full paper, visit the original source.