Meet Dinesh: One with a continuous improvement mindset — Part 1.

Hey! Welcome to Zeta Scoops — an infinite-part series on the life and times of Zetanauts modernizing banking tech globally.

Life At Zeta
6 min readMay 23, 2024

In this edition, we feature Dinesh, a Product Security Engineer, and learn the steps he took to ensure a 100% secure infrastructure. Because of the magnitude of security-based information shared, the story is divided into two parts.

Cyber security is key to running a successful tech business, especially when your business operates in the banking sphere. The first lapse in security is probably the last nail in the coffin. Naturally, we doubled our security parameters and made our systems breach-proof. However, building a robust security and surveillance system requires thinking ahead of attackers and ensuring all corners are covered. Dinesh C led this initiative and ensured everything was bolted down and secured.

In this blog, we will discuss the different practices and methods Dinesh deployed to build a security parameter and also discuss his out-of-the-box approach to enhancing security.

Getting the house in order

“Building clean codes is winning half the battle,” says Dinesh. “Most threats are outcomes of vulnerabilities occurring in the code itself. It is, therefore, crucial to ensure clean code goes into production,” he adds.

To this end, Dinesh sleuthed through different security tools and froze on Snyk Checks. “Snyk Checks offers a powerful suite of features and advantages to streamline the process of code review and enhance security within the development pipeline,” he notes with a tone that reminds you of your strict college professor. Fun fact: Dinesh loves teaching. He often explains engineering concepts and methods to his colleagues and juniors. “I think there’s a great satisfaction in disseminating knowledge,” he adds — again with an air of academic solemness.

Understanding Snyk PR Checks

Snyk PR Checks is a solution designed to seamlessly integrate security checks into the pull request (PR) workflow. By automatically scanning code changes for vulnerabilities and violations as they are submitted, Snyk PR Checks empowers development teams to identify and remediate issues early in the development lifecycle, minimizing the risk of shipping insecure code to production.

But why Snyk?

“A few key features of the tool made it stand out from the rest”, submits Dinesh. These key features are:

Key Features

1. Real-Time Security Scanning

Snyk PR Checks provides real-time security scanning of code changes within the PR environment. Snyk identifies potential security risks and highlights them directly within the PR interface, enabling developers to take immediate action to address issues before they escalate.

2. Dependency Analysis

Snyk PR Checks performs thorough dependency analysis, alerting developers to outdated or vulnerable dependencies that may introduce security vulnerabilities into the application.

3. Customizable Policies

It offers customizable policies that allow teams to define their security standards and best practices. Whether enforcing specific vulnerability thresholds or ensuring compliance with industry regulations, Snyk PR Checks allow teams to tailor security policies to their specific needs.

4. Actionable Insights

Snyk PR Checks provides actionable insights and remediation guidance to help developers address issues effectively. By offering clear, contextual feedback directly within the PR interface, Snyk enables developers to make informed decisions and implement fixes quickly, reducing the time-to-resolution for security issues.

5. Seamless Integration

Snyk PR Checks seamlessly integrate with popular version control systems like GitHub, GitLab, and Bitbucket, making incorporating security checks into existing development workflows easy.

These features not only gave developers access to opportunities to ensure the code they are pushing is clean and fix errors immediately, but this vetting at the source drastically reduced vulnerabilities and ensured instant error detection and resolution.

The tool ensured:

  1. Improved code quality
  2. Enhanced Security
  3. Streamlined development workflow
  4. Compliance assurance

Here’s how a sample Snyk PR check looks like:

Dealing with external threats

Once Dinesh had bolted down security parameters to fix internal vulnerabilities, it was time to catch external vulnerabilities.

As organizations increasingly rely on open-source components, the threat of malicious agents penetrating the system has increased. To counter this, Dinesh delved into figuring out best practices — from a security point of view — for dealing with open-source licenses.

Before we proceed, let’s spend some time understanding open-source licenses. These licenses govern the use, modification, and distribution of software. Security considerations become paramount as these projects may be integrated into critical systems.

There are five types of licenses overall. Notably, Dinesh was more inclined to explain this in-depth, even going against the author’s recommendation of keeping it short. “People must know what these licenses are,” he said while practicing absolutely no restraint on this educator persona.

Here’s a quick rundown of what these licenses, along with their restrictiveness:

  1. Public Domain License: Anyone is free to use and modify the software [No restrictions]
  2. General Public License: You can link to open-source libraries within your own software [mildly restrictive]
  3. Permissive: Few restrictions or requirements for the distribution or modification of the software
  4. Copyleft: Restrictive — known as reciprocal licenses [Modereately restrictive]
  5. Proprietary: Ineligible for copying, modifying, or distribution [Most restrictive]

Out of the five listed, there are two key types of restrictive licenses:

  1. Permissive Licenses: The most popular permissive open-source licenses are Apache, MIT, BSD, and Unlicensed, providing considerable freedom. While they allow for flexibility, developers must diligently review the security practices of the projects they incorporate.
  2. Copyleft Licenses: Copyleft is a method of making intellectual property reusable and modifiable without any restrictions. Anything new produced using the original asset must also be freely available. This can apply to everything from works of art to software.

Copyleft is the opposite of copyright and is used widely in Open-Source development. The copyleft license allows creators, contributors, and maintainers to make changes to open-source projects and share them with the community.

Choosing the right license for security

“This is the starting point for all external source scanning”, explains Dinesh, “This is perhaps the most important aspect of security licensing”.

There are two main factors to consider when choosing a license:

  • Risk Tolerance: We must use a permissive licence so that we need not open source Zeta code/intellectual property; if we use a copyleft licence we might end up disclosing our intellectual property
  • Legal Counsel: Consult with legal professionals to ensure that the chosen license aligns with security and business objectives. Legal guidance can help navigate the complexities of open-source licensing and compliance.

Free and Open Source Software (FOSS) Assessment Risk Assessment

“Free and Open Source Software (FOSS) Risk Assessment is the process of evaluating the potential risks and benefits associated with using, contributing to, and distributing FOSS in an organization”, explains Dinesh.

This assessment helps organizations make informed decisions about integrating open-source software into their operations by identifying and mitigating potential legal, security, operational, and compliance risks.

Steps in conducting FOSS assessment

Here are some key steps, as Dinesh explains, in conducting an effective risk assessment:

  1. Inventory and Classification:
  • Create an inventory of all FOSS components used in the organization.
  • Classify the components based on their criticality to the business operations.

2. License Analysis:

  • Review and analyze the licenses of the FOSS components to understand compliance requirements and restrictions.
  • Document the obligations for each license type.

3. Security Evaluation:

  • Conduct a security assessment of the FOSS components to identify vulnerabilities.
  • Implement a process for continuous monitoring and patch management.

4. Community and Maintenance Review:

  • Assess the activity and health of the FOSS project’s community.
  • Evaluate the project’s update and maintenance frequency.

5. Legal Review: Consult with legal experts to understand potential IP risks.

  • Ensure proper documentation and legal clearance for using FOSS.

6. Operational Impact Analysis:

  • Analyze the impact of integrating FOSS into existing systems.
  • Plan for support and maintenance strategies.

7. Compliance Check:

  • Ensure that the use of FOSS complies with relevant regulations and standards.
  • Align with internal policies and procedures.

“A comprehensive FOSS Risk Assessment helped us leverage the benefits of open-source software while mitigating potential risks, ensuring compliance, and maintaining security and operational integrity.” Says Dinesh.

There’s a whole lot more to creating a robust security environment. That will be discussed in part 2 of this blog series with Dinesh!

But for today, as Dinesh likes to put it, the class is adjourned!

#WeAreZetanauts, and we’re always looking for folks to join us on our mission to revolutionize the banking sector. If you think you have it in you to take on frontier challenges and build the next generation of banking tools, follow us on LinkedIn and apply for a role here.

--

--

Life At Zeta

Stories of folks building the next generation of banking technology.