Article

Category: Expert stories

Best practices in Software Supply Chain Security 

In this article, software architect Mateusz Pruchniak presents key practices in software supply chain security that allow organizations to minimize the risk of security gaps and threats related to software delivery.

Mateusz Pruchniak, Warsaw

The software supply chain is the 'process of delivering a product to the customer' in the IT domain, referring to the process of designing, building, delivering, and maintaining.

Software supply chain security is a crucial aspect of the contemporary IT world. As technology evolves, an increasing number of organizations and businesses rely on software delivered from various sources, which creates gaps in its security posture.

This article will discuss various aspects of software supply chain security, starting from securing source code to securing deployment processes. I will present software supply chain security practices divided into 5 stages.

 

Attack on Sunburst

The IT world paid significant attention to supply chain security after the high-profile attack on SolarWinds, known as Sunburst. It was one of the most serious cyber incidents and took place in December 2020.

The attack began by compromising the infrastructure of the software provider SolarWinds to inject malicious code into the popular SolarWinds Orion software, responsible for monitoring and managing computer networks.

supply-chain-security_body-image-2

It was a sophisticated and complex attack that led to security breaches in many critical institutions, including governments, companies, and organizations worldwide. The infected software version was installed for over 18,000 customers.

The insecurity of the software supply chain can lead to serious consequences, such as data breaches, user privacy violations, critical system disruptions, and a negative impact on a company's reputation. As a result, developing and implementing best practices in security has become an essential element of technology-based business strategies.

 

Securing Source Code

The foundation of every software supply chain is its source code. The code repository should be treated as a standard production system and secured in the same manner, considering the principle of least privilege and separation of duties.

Recommended practices:

  1. Enable MFA (Multi-Factor Authentication) for accessing the SCM (Source Code Management) system - multi-factor authentication should be required and enforced to add an extra layer of security.
  2. Use SSH keys to grant developers access to the source code repositories - Instead of relying on login/password credentials, which are susceptible to typical hacking techniques such as brute force attacks or password guessing, it is recommended to use SSH keys or SSH certificates. If not possible, consider using frequently rotated access tokens as an alternative.
  3. Require signed commits - signing the source code (commits and tags) ensures integrity, non-repudiation, and auditability. The most popular mechanisms for signing are GPG-based mechanisms, although S/MIME certificates are also used for this purpose.
  4. Enable or implement change scanning and blocking mechanisms - Block the ability to save passwords, certificates, keys, and tokens in the code repository to prevent accidental exposure of sensitive information.
  5. Separate responsibilities and duties between distinct teams - Separate the teams responsible for modifying the source code from the administrators responsible for configurations, validations, and policies imposed on the code repository.
  6. Enforce code review before merging changes (Pull Request, Merge Request). The author(s) of the changes should not be the same person approving the changes (four-eyes principle).
  7. Regularly perform backups - make backups of the code and store them in a secure location. Backups can be used by verification tools to ensure the repository's integrity.

 

  The insecurity of the software supply chain can lead to serious consequences, such as data breaches, user privacy violations, critical system disruptions, and a negative impact on a company's reputation.

 

Illustration of a solid chain with code written in the metal

Securing Dependencies

Dependencies on external libraries are an integral part of the software building process. However, they also come with certain challenges, such as managing library versions, ensuring that libraries are secure and up-to-date, and identifying and resolving conflicts between different libraries.

Recommended practices:

  1. Verify the source of external libraries - before using an external library, it is essential to verify its authenticity and origin. It is best to obtain libraries from official sources, such as official websites, official repositories, or other reputable distribution channels. A good practice is to copy dependencies to a secure, protected private repository.
  2. Verify integrity - ensure that downloaded libraries have not been modified during transport or download. Verifying the checksum can help ensure that the downloaded library is identical to the original file.
    Verify vulnerabilities - before using an external library, it is worth conducting an analysis of potential vulnerabilities that may exist in a given version of the library. There are specialized tools for automatically scanning libraries for known vulnerabilities, such as SAST (Static Application Security Testing) tools or OWASP Dependency-Track.
  3. Monitor vulnerabilities - it is valuable to keep track of current security information related to the used libraries, such as notifications about detected vulnerabilities and the availability of fixes. This way, potential threats can be quickly addressed, and updates can be applied.
  4. Verify licenses - remember that security is not the only aspect to consider. Legal aspects are also essential. Software often utilizes open-source or commercial libraries, which are available under various licenses. It is crucial to meticulously verify the licenses of these libraries or other dependencies.

 

  Security is not the only aspect to consider; legal aspects are also essential. Software often utilizes open-source or commercial libraries, and it's crucial to meticulously verify the licenses of these libraries or other dependencies.

 

Securing Build Pipelines

Securing the compilation and build processes of software is a fundamental element of ensuring the security and integrity of the final software product. At this stage, the software is compiled or built from source code and external dependencies. Incorrect and insecure configurations can undermine all the efforts made to secure the source code and external dependencies.

Recommended practices:

  1. Secure the infrastructure - the infrastructure used for compilation and building should be secured in the same way as the production infrastructure. Applying production-like controls will protect against unauthorized changes to the infrastructure (four-eyes principle), unauthorized configurations, and ensure monitoring (SIEM), update processes, and vulnerability scanning.
  2. Minimize infrastructure sharing - shared infrastructure (e.g., virtual machines) can lead to vulnerabilities in one technology being exploited to compromise the compilation or build process of other software. The best practice is to use pre-prepared, secured container images for one-time execution of the process and then delete them after use. Images should contain only the necessary tools and binaries required for the specific process they are responsible for, as well as the narrowest range of permissions and network access.
  3. Store pipeline configurations as code - configuration should be implemented as code and treated as immutable ("pipeline as code"). Apply the same practices as mentioned above for source code.
  4. Include tests and quality gates - add automated software quality assessments at various stages of the pipeline. Quality gates can be configured and tailored to the specific project's needs and organizational requirements.
    Sign output and intermediate artifacts - to ensure integrity and repeatability of the process and artifacts, each individual step in the process requires signing. The set of signatures is included in the final artifact package, ensuring the integrity of the entire artifact and its related metadata.
Artboard 3

Securing Artifacts

Dependencies on external libraries are an integral part of the software building process. However, they also come with certain challenges, such as managing library versions, ensuring that libraries are secure and up-to-date, and identifying and resolving conflicts between different libraries.

Recommended practices:

  1. Verify artifact signatures - verification of artifact signatures should occur at the moment of adding the artifact to the repository. This ensures that only trusted and signed artifacts are allowed in the repository.
  2. Limit access - restrict access to the artifact repository only to individuals who require it. Utilize strong password-based authentication, SSH keys, or certificates.
  3. Segregate responsibilities - implement the principle of Separation of Duties to separate responsibilities for the artifact repository to avoid conflicts of interest, abuses, and limit the risk of potential threats. Regular monitoring and review of assigned permissions are also crucial.
  4. Regularly backup - create backups of the artifact repository and store them in a secure location. Ensure that data recovery procedures are tested and accurate.
  5. Audit access - monitor and log attempts to access the artifact repository. Review logs to identify suspicious activities and unauthorized access attempts, especially on modification operations outside the automated process. This helps detect and respond to potential security breaches promptly.

 

The deployment pipeline should be designed in a way that enables automatic and controlled deployment of artifacts, while maintaining the highest security standards.

 

Securing Deployment Pipelines

Having a secure source of trusted artifacts (meaning that we store trusted and verified software) requires developing a secure deployment pipeline for these artifacts to various environments, including production environments. The deployment pipeline should be designed in a way that enables automatic and controlled deployment of artifacts, while maintaining the highest security standards.

  1. Segregate environments - implement environment segregation to keep non-production and production environments separate. Limit access to production only to authorized personnel, reducing the risk of introducing errors into the production environment.
  2. Segregate responsibilities - similar to previous steps, individuals responsible for deploying software to the production environment should be independent of those responsible for developing and testing the software.
  3. Automate - use tools for automated software deployment from trusted artifact sources, and validate artifact integrity through signature verification.
  4. Monitor and log - monitor the deployment process and log information for auditing and informational purposes.

Read also:
Cybersecurity in the age of phishing - how you get tricked

Ready to grow?

Get help with your CV and profile and be found for rewarding projects.

Register your profile

Blog

Read more

See insights

left-arrow
right-arrow

Man and woman speaking on their way through the office.
Expertise strategy
Managed Teams & Managed Service

From partner to problem: 5 red flags in your supplier setup

IT outsourcing once felt like a game-changing lifeline: efficient, cost effective and freeing up focus. But how do you know when it’s time to pull back? These 5 red flags could signal that your supplier setup might be holding you back.
Two young professionals sitting in a meeting.
Expertise strategy
Tech & Development

IT leaders are reclaiming control – here’s why

The IT landscape is shifting fast. As old outsourcing models show their cracks, forward-thinking leaders are rebuilding internal strength and redefining what smart partnerships look like. A trend is emerging where decoupling and taking back ownership takes the stage.
Bestshoring
Expertise strategy

Offshoring Part 2: What offshoring means to emagine

In this article, Martin Hartley, Group CCO at emagine, explores how we approach offshoring – not just as a cost-saving measure, but as a strategic extension of our delivery model.