Polyglotism effects on security

Microservices development introduced and changed organisations' flexibility, ownership, scaling and domain-based systems. Monolith was the pre-cursor, not the immediate pre-cursor. there were precursors such as SOA. Infrastructure orchestration tools such as k8 made the adoption of microservice architecture and operations easier.

With microservices came service ownership and service boundaries. Each service can decide its own performance and quality. This paved the way for polyglots. Each service can choose the programming language of its choice, database and data ETL( polyglot persistence ), infrastructure, and API communication.

I have represented the programming language in a triangle object, the Database in a rectangle object, the Infrastructure in a circle object, and API communication in a star object.

Service 1 aka SVC 1 uses GO programming language, PostgreSQL DB, Google Managed Kubernetes Engine ( GKE ) and gRPC for API service communication. The same, is seen for Service 2 . SVC 2 has an additional job service that is deployed in AWS lambda function and uses Python language with HTTP 2 as communication ( to start, check the health etc). Though you can raise the question of why AWS lambda function, let’s take for an example that AWS lambda uses Bedrock AI API and the code is tightly integrated.

The problem arises in reviewing the code. Since both services use three different languages such as Python, Java and GO. Security Engineer has to know the pitfalls, misconfiguration code all in his mind to review the code. Do you think that code reveiw is efficient in this case?. Do you think manual code review is scalable? First of all, is it needed? I believe it is better to delegate to SAST Tools. SAST tools cover most of the languages business uses and it is capable of doing a good job.

What does a good manual security code review mean?

Knowledge of bad (insecure) functions, the intricacies of each programming language and its impact is needed for a good security code review. For example, Memory injection/manipulation vulnerabilities in c have a greater impact than in Java, go. Some vulnerabilities in one programming language might differ in other programming languages. Just because you can read and understand the code, it does not mean you know the intricacies of the language. SAST vendors have a security research team to uncover, monitor new vulnerabilities and create SAST rules. The percentage of security engineers creating SAST rule is so minimal and not needed because of market forces involved.

Why Security code review is getting difficult? If you found an issue by manual secure code review, how do you prioritise it? it can be conveyed by telling the impact of the bug caused but is it going to be reachable? . The efficient case of manual secure code review is dependent on the developer fixing the findings. if the developer needs security team to give impact to prioritise the issues, then we should be able to do it. In that case, SAST already solves it. Certain SAST vendors have reachability analysis and prioritisation techniques rather than manually figuring out what to do and that is time-consuming.

Market forces

Security functions are invested less, struggling to meet the ends, making sure the lights are on. We are running on low oil. Manual Secure code review will be the least prioritised and does not bring an ROI rather than delegate to SAST tools and scale it. If the market forces continue, Manual secure code review will sunset aka dead in the coming years.

To note:

1. Understanding code is needed to review the application. Because code tells the truth, knowing how to understand and write code is important for a security engineer

2. Code review can be combined while doing whitebox testing which is properly planned and code review gives you an upper hand to discover vulnerabilities. Here, I am talking about the case of reviewing the code manually for all PR’s or prioritised PR’s which is done as a process. Better Appsec gives you an idea of Secure Code Review process https://betterappsec.com/building-a-practical-secure-code-review-process-cdee8ebf68c8 . The argument from my side is that SCR described by better appsec does not work in the present market force and polyglotism introduced from mircoservice architecture with limited investment and soon SCR will sunset.

There are other issues that emerges from microservice and service polyglotism

1. Setting standards is difficult across services.

2. The centralised Security team model does not have the proper knowledge as service-based security team has. The centralised security team are expected to know all misconfigurations and vulnerability patterns which is a huge responsibility and ownership. Service-based security teams can hire security engineers according to the service stack and service needs. The downside, investment is needed and hiring skilled security engineers gap.

3. All security reviews such as infra review and code review will be delegated to tools to scale. why is it delegated?. it is because both knowledge and capability to provide information to fix them tasks take a considerable amount of time by performing it manually and with the addition of less investment in security teams, security tools are preferred. This paved way to platformisation adoption such that you do not have to handle multiple tools, you can have a single pane of view in one platform.