open source

Best practices to secure open source software

The use of open source software is on the rise. With the constant need to cut costs and reduce the time for software development, it is no secret that a majority of companies use open source components extensively. This is particularly true for startup firms that find open source extremely attractive. This includes lower costs to deploy software as there are no license costs. Open source also gives startups the ability to level the playing field with the freedom to deploy the latest technologies without the upfront capital costs.

That said, open source, like any other comparable software, can contain security defects. Github, one of the largest platforms for open source in the world, published its annual report in December last year, which highlighted some interesting facts about open source vulnerabilities. The report stated that security vulnerabilities often go undetected for more than four years before being disclosed. The nature of open source, makes the code vulnerable, because of dependencies. The dependencies may contain vulnerabilities. Github states that in modern software, 80% of application code may come from dependencies.

The reasons for vulnerabilities can be attributed to a host of reasons. Speed is the essence for many emerging companies and startup firms. In the tradeoff between moving quickly and developing software, many startups don’t focus on writing secure code. Additionally, most of the open source experiments happen in a non-production environment. And that is where the weak link in security can creep in. Many developers believe that since this is a non-production environment, the required security protocols do not need to be adhered to.

Additionally, today, developers have access and the choice to choose different cloud environments. It is common to see developers start off by using their personal cloud account in public cloud environments. Once a code is deemed to be successful, developers transfer it to the company account. This transition happens quickly, as developers and the company wants to contribute to faster development and release. This code never passes through any security protocols, as the assumption is that a code that worked in a personal account will work properly in the production environment. This is a normal activity in most startup firms, as most startups have limited resources, and are given the freedom to experiment without any restrictions. But in reality, this is one of the root causes of vulnerabilities, as it can cause a vulnerability to move unchecked from a private to an enterprise environment very easily.

The importance of ‘Shift left’

A well-known concept among major software developers, ‘Shift Left’ means introducing security at the earliest possible point in the software development lifecycle (SDLC). This approach is important when you look at the way software code is developed and put into production. Developing an app starts from documenting, coding and then following a process of build, test, release and deploy.  Every team has a different responsibility. Developers are tasked with writing and testing the code, while the DevOps and Ops teams are responsible for building the system. The security team comes in play, once the code is in production. As both development and production environments were separate, the thinking was that the security team could just focus on securing the production environment.

However, today, with the rise in automation, this is no longer a viable approach.  A majority of the development processes are automated by tools such as Jenkins (which runs the Continuous Integration/Continuous Delivery pipeline) or Ansible (which is responsible for putting the code into production). Due to automation, security is not involved till deployment. This is dangerous and the code can have several vulnerabilities. It is hence advisable for security to ‘Shift Left’ and be involved right at the start of the development process, so that at each step, adequate security best practices with respect to coding practices are followed.

A common mistake is to hardcode credentials and access keys into the application code. This can be exploited by hackers to gain access to credentials used by applications and get access to databases or cloud platforms. To prevent such issues, enterprises can consider offering self-service solutions, such as an automated approval process that helps developers to request security policy updates that allow their apps to access secure resources. This helps enterprises automatically route developer requests to securely access resources and route only exceptions to the security team. This can be complemented by code scanning tools that can prevent any viruses or vulnerability from being incorporated into the application. In addition, software testing can be automated so that developers are immediately alerted of any deviations from secure coding practices.

Open source is here to stay, and will occupy a much bigger percentage of application code. Hence, it is vital that developers embed security as a natural part of their coding process. Considering the rising usage of open source in every software application, it is critical that enterprises invest time and attention to weed out possible vulnerabilities. Currently, enterprises get penalized if there is a data breach or when things go wrong with respect to security. It is time to change this approach, and we must incentivize people for trying to keep the world safe. If developers get incentivized for developing secure code or ensuring that their code adheres to the best security practices possible, then it can make a huge difference in the attitude and approach of developers. Most developers start using open source components when they are young. This is also true for most startups who employ young developers. Once developers get used to secure development practices, then it can lead to a major behavioural change, which can lead to a huge transformation in the way the world creates applications.

This is also a wakeup call for CISOs and they must be proactive in securing code using centralised credential management. CISOs must recognize the fact that software developers will be the roles most targeted by hackers, as they are the ones building the kingdom (the software), and have the master keys to the doors of the kingdom (via administrative privileges).

CISOs can address this issue by using a centralised credential management solution or a privileged access security solution, that eliminates hard coded application credentials embedded in applications, scripts or configuration files (a common mistake of developers), and allows passwords or credentials to be stored and managed centrally. This approach helps organisations to comply with internal and regulatory compliance requirements and monitor privileged access across all systems, databases and applications.

The article has been written by Rohan Vaidya, Regional Director – India, CyberArk

Leave a Reply

Your email address will not be published. Required fields are marked *