The use of free software is increasing. With the constant need to reduce software development costs and time, it’s no secret that a majority of companies are heavily using open source components. This is especially true for start-ups who find open source extremely attractive. This includes lower costs to deploy the software as there are no licensing costs. Open source also gives startups the ability to level the playing field with the freedom to deploy the latest technology without the upfront capital costs.
That said, open source, like any comparable software, can contain security flaws. Github, one of the largest open source platforms in the world, released its annual report in December of last year, which highlighted some interesting facts about open source vulnerabilities. The report says security vulnerabilities often go undetected for more than four years before being disclosed. The nature of open source makes the code vulnerable, due to dependencies. Dependencies can contain vulnerabilities. Github states that in modern software, 80% of application code can come from dependencies.
The reasons for vulnerabilities can be attributed to a multitude of reasons. Speed ââis the essence of many emerging businesses and startups. In the trade-off between rapid change and software development, many startups don’t focus on writing secure code. Additionally, most open source experiences take place in a non-production environment. And this is where the weakest link in security can sneak in. Many developers believe that since this is a non-production environment, the required security protocols do not need to be followed.
Moreover, today developers have access and the choice to choose different cloud environments. It’s common for developers to start using their personal cloud accounts in public cloud environments. Once a code is considered successful, developers transfer it to the company’s account. This transition is happening quickly, as developers and the business want to contribute to faster development and release. This code never goes through any security protocol, as the assumption is that code that worked in a personal account will work fine in the production environment. This is a normal activity in most startups, as most startups have limited resources and have the freedom to experiment without any restrictions. But in reality, this is one of the root causes of vulnerabilities, as it can lead to the uncontrolled shift of a vulnerability from a private environment to a corporate environment very easily.
The importance of “shifting to the left”
A concept well known to leading software developers, “Shift Left” means introducing security as early as possible in the Software Development Lifecycle (SDLC). This approach is important when you examine how software code is developed and released into production. Developing an application begins with documenting, coding, and then following through a process of building, testing, releasing, and deploying. Each team has a different responsibility. The developers are responsible for writing and testing the code, while the DevOps and Ops teams are responsible for building the system. The security team comes into play once the code goes into production. As the development and production environments were separate, the idea was that the security team could focus only on securing the production environment.
However, today, with the rise of automation, this approach is no longer viable. A majority of development processes are automated by tools such as Jenkins (which runs the continuous integration / continuous delivery pipeline) or Ansible (which is responsible for putting code into production). Due to automation, security is not involved until deployment. It is dangerous and the code can have several vulnerabilities. Security is therefore advised to “shift left” and be involved from the start of the development process, so that at every step the appropriate security best practices with regards to coding practices are followed. .
A common mistake is to hard-code credentials and access keys into application code. This can be exploited by hackers to gain access to credentials used by applications and to gain access to databases or cloud platforms. To avoid such problems, companies may consider offering self-service solutions, such as an automated approval process that helps developers request updates to security policies that allow their applications to access. to secure resources. This helps organizations automatically route developer requests for secure access to resources and route only exceptions to the security team. This can be supplemented with code analysis tools that can prevent the integration of viruses or vulnerabilities into the application. Additionally, software testing can be automated so developers are immediately alerted to any deviation from secure coding practices.
Open source is here to stay and will take up a much larger percentage of application code. Therefore, it is essential that developers integrate security as a natural part of their coding process. With the increasing use of open source in every software application, it is essential that companies invest the time and attention to eliminate possible vulnerabilities. Currently, companies are penalized for data breaches or security concerns. It’s time to change this approach, and we need to inspire people to try to keep the world safe. If developers are incentivized to develop secure code or ensure that their code adheres to best possible security practices, 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 that employ young developers. Once developers get used to secure development practices, it can lead to a major change in behavior, which can lead to a huge transformation in the way the world creates apps.
This is also a red flag for CISOs and they need to be proactive in securing code using centralized credential management. CISOs need to recognize that software developers will be the roles most targeted by hackers, as they are the ones who build the kingdom (the software) and hold the master keys to the kingdom’s doors (via administrative privileges).
RSSIs can solve this problem by using a centralized credential management solution or a privileged access security solution, which eliminates hard-coded application credentials embedded in applications, scripts, or software. configuration files (a common developer mistake), and allows passwords or credentials to be stored and managed centrally. This approach helps organizations comply with internal and regulatory compliance requirements and monitor privileged access across all systems, databases and applications.
The article was written by Rohan Vaidya, Regional Director – India, CyberArk