APIsecurity.io - APISecurity.io Newsletter: Issue 159

This week, SonarSource warned of a highly critical vulnerability in the common open-source CI/CD system, GoCD. The vulnerability could allow attackers to gain access to critical pipeline data, including secrets such as API tokens or credentials for downstream supply chain elements.

The vulnerability was caused by shortcomings in how GoCD build agents (aka workers) authenticated themselves to the GoCD master, which allowed fake agents to be inserted into a pipeline. Once an agent had been enrolled into a pipeline, it then had access to all tokens and secrets within the CI/CD pipeline as well as the ability to execute arbitrary code within the context of the pipeline.

Although organizations typically deploy build agents on internal networks where they are protected from impersonation by rogue agents, there are several hundred instances of GoCD exposed to the internet.

The affected versions of GoCD range from v20.6.0 to v21.2.0, and the vulnerability has been resolved in version v21.3.0, so if you are affected, patch yours as soon as possible.

The key takeaway here is that the CI/CD system is a vital component of supply chain infrastructure and should be protected at a variety of levels. 2022 is likely to become the year of supply chain attacks!

SecurityBoulevard featured an excellent case study from Raiffeisen Bank International (RBI) based on an interview with Peter Gerdenitsch, Group CISO at RBI.

Gerdenitsch describes how RBI made a shift toward a product-led agile structure in 2019. This transition included the role of Security Champion within each of the product DevSecOps teams:

Security Champions lead in all aspects of product security within their business unit. A key point to the role is that it is a volunteer-driven role. RBI’s experience was that they had no shortage of volunteers and that they got much interest from a variety of disciplines within the organization. As with many popular Security Champion programs, RBI opted to use the martial arts’ belt system, shown below:

In terms of API security, the blue belt level included specialized courses just on API security and at the black belt level the focus was on hands-on manual pentest skills.

As regards to APIs, RBI had a large estate — 100 external APIs under Payment Service Directive (PSD) scope, plus a thousand or more internal APIs on top of that. As is typical in large organizations, RBI found that what they lacked was an extensive inventory of their APIs. They addressed this with Real-Time Integration Center of Excellence (RICE), which acted as a central management layer for all RBI’s APIs. Another key approach was to ensure that both the product owner and the IT security teams were involved in securing their APIs.

This case study is a highly recommended read for anyone wanting to scale their API security initiatives, and particularly useful for security and AppSec leaders tasked with the responsibility of incorporating API security into their portfolio of coverage.

DarkReading has featured an article on why API security is hindering application delivery.

According to research from Cloudentity, key findings are that nearly all organizations have experienced delays in releasing new applications or updates due to concerns for the security of their API environment.  Approximately 44% of them say they have experienced API security issues, such as data leakage and exposure of private information.

As possibly expected, the most commonly cited reasons for this predicament include:

• The high financial costs associated with API security
• The demands of faster application delivery timelines
• A lack of awareness regarding API security

The report concludes that API security is likely to received increased focus and attention and — correspondingly — increased budgets in the coming years.

Finally this week, a brief piece from in HelpNetSecurity on a recent F5 report detailing the continued sprawl of APIs. According to the report:

“We estimate that the number of public and private APIs today is approaching 200 million, and by 2031 that number could be in the billions”

The reasons for the increased sprawl stated in the report include:

• A lack of global standards leading to re-implementation of APIs
• The growth of microservices
• Increased software released cadences
• Increased interoperability required within large enterprises
• Siloed business units duplicating the effort

The increased sprawl leads to increased operation and security challenges, making it something to keep an eye on in terms of API security.