How to ensure the security of your applications despite outsourcing their development?

 

Integrating security into projects is an important process for companies to define and integrate security aspects into products as early as possible. This avoids increasing the cost of remediation if it has not been planned and is implemented at the end of the project.

In the context of developments, Agile Security and DevSecOps define the processes and tools to be put in place to integrate security as early as possible, as presented in our previous article giving examples.

These methods are often defined on internal developments. However, it is often the case that companies call on external service providers to develop a particular application or functionality. In this case, it is important to ensure that these providers follow rigorous security practices and that they integrate security into their development processes to the same standards as the requester. This leads to the following question:

 

External developments: how to maintain confidence in externally developed code?  

In the remainder of this article, external code is defined as all code elements that have not been developed through an internalised CI/CD chain. For example, a freelance developer using the internal CI/CD chain or an enterprise workstation is not considered external code.

In addition, we will consider two models of application delivery depending on the development model used by the provider:

• delivery of the source code itself
• delivery of the executable, i.e. the already precompiled code

It is important to note that these two application delivery models have different implications in terms of cyber security and DevSecOps.

 

Code delivery

In the case of code delivery, external providers hand over the code they have written, usually in the form of source files (e.g. .java files for Java code), to the company. The company can then audit, compile and deploy the code on its own servers.

Code delivery has several advantages. The first advantage is flexibility: by delivering the source code, the company can easily make changes and customisations to the code. It can also integrate the code into its existing development and deployment environment (CI/CD) containing all the pre-configured security tools.

The company then does not have to place its trust in the security of the provider’s CI chain over which it has no control. In addition, the company with access to the source code can also audit it and thus verify that it is secure. These audits tend to be more comprehensive as the auditor has access to much more detail about the operation of the code and can perform both static and dynamic analysis of the code.

On the other hand, code delivery has some disadvantages. The company must have the skills to adapt the build and deployment stages to the production context. If these skills are not available in-house, this can lead to additional costs.  

Here are some good practices to maximise confidence in the delivered code:

• Share as early as possible (contract, kick-off meeting) the expected requirements on security in development, software versions, internal tooling used for deployment, confidentiality of source code, etc. Some clients require external developers to have a certain level of certification or training (for example, a level of training on Secure Code Warrior, in a certain programming language).
• Define and contractualise commitments on the remediation processes for identified vulnerabilities after code delivery and the associated monitoring (monitoring tools, SLAs, etc.)
• Implement a hash or signature type control on the code sent to ensure its integrity and define the methods for secure transfer of the source code with the service provider
• Integrate the code received into the existing CI/CD chain, including the Infrastructure as Code (IaC) files
• Carry out the functional security tests initially defined during the threat modelling: Evil User Stories and Security Stories

 

Some organisations may be faced with a situation where the notion of external developers corresponds to developers from other entities within the same group. These entities may have their own CI chains but depend on the CD or CI/CD chain of the central production team.

In these cases, an interconnection of the different CI chains to the central CI/CD chain can be considered. This solution allows the different teams to develop with the tools that best suit them.

 

The level of security provided by the project CI/CD chain is ideally equivalent to that of production but this is not necessarily the case. The production CI/CD chain controls the code to be deployed.

However, security control is often carried out too late in the development process. To ensure effective security in developments, it is crucial to ensure that security is integrated from the beginning of the development cycle (shift-left). To address this, it is recommended to provide self-service security tools for project teams to identify vulnerabilities early in their development using the appropriate target tools.

Otherwise, the security tools in the production CI/CD chain will ensure compliance with the group’s rules without slowing down the production release if automated security controls have been put in place within the project chain.

This solution also allows production to ensure the use of images (systems, docker, etc.) or artefacts (libraries) validated by the company.

These interconnections between the different pipelines can, for example, clone the branch to be deployed by the product team in order to push them into the CD chain. However, the production teams must have the appropriate rights. Technically, the model for managing the rights granted (ideally temporarily) must meet both the need to facilitate execution and the need for rights provisioning (manual vs. automatic), while limiting access to all branches or projects in order to respect the principle of least privilege.

Most of the good practices mentioned above also apply to reduce the time to production.

Although the methods described above appear to be the most effective for gaining control over applications developed by third parties, companies sometimes find themselves receiving executables without access to the source code. This may be due to licensing restrictions, for example. In this case, some of the good practices outlined above do not apply, and it is necessary to rethink how to integrate changes into production so as not to neglect certain security aspects.

 

Executable delivery

In the case of executable delivery, external providers hand over an executable file (e.g., an .exe file for Windows servers) that can be directly executed by the company without compilation. This delivery method is often used for commercial software that still requires some configuration adjustments.

In this context, the integration in the deployment chain is much more limited and only a few classical CD steps can be performed without the security steps of the CI chain being verified:

• Performing an artefact scan
• Performing a DAST scan to detect the most common vulnerabilities
• Performing penetration tests

Reports from the security tools of the development provider’s chain can also be requested. This must be included in the service contract, along with the security requirements for the level of security of the code.

Finally, a signature of the code to ensure its integrity is necessary at the time of the exchange and the executable. For this purpose, it is better to use signatures via certificates rather than hash prints, since the latter make it possible to verify the origin (non-repudiation) in addition to the integrity of the executable.

 

In conclusion, it is important for companies to ensure the quality and security of the code delivered by external providers, especially when the latter are developing code on external CI chains. There are several ways to convince yourself of the security of the delivered code:

• Clear and precise contractual clauses can help define the expectations and responsibilities of each party with regard to the quality and security of the code.
• Sharing specifications and security expectations with external providers can also help ensure that the delivered code meets the company’s requirements.
• Integration with internal development chain tools can facilitate verification of code quality and security, as well as the implementation of automated testing. These integrations raise both technical and process challenges that must be anticipated to facilitate the deployment of external developments.

By implementing these different approaches, companies can increase their confidence in the code delivered by external providers and ensure the security of their application.