We Improved & Automated our Security Systems with a Smart Tweak. Here’s How

Security systems restrict vulnerability exposure and form a crucial part of the code flow. But when your engineering team pushes out tons of codes everyday, scanning can become tedious. Here’s how we streamlined & automated this process.

My first engineering project was building a water filtration system.

We had studied and taken apart an RO filter to figure out how it worked and created our own filtration device. We made a series of chambers, each performing some form of purification.

The filter cartridge removed dirt and mud before pushing the water into the next cartridge, where finer particles were filtered out. The water then moved into the chemi-block chamber and then into the RO membrane, where dissolved chemicals and microorganisms, bacteria, etc were removed respectively. The final chamber segregated the clean and rejected water and out came clean sparkling H2O.

It’s been a while since that experiment and now I am again taking apart and analysing a contraption, one that filters out ‘defects’, but at a quantum level.

In this blog, I will tear down the set-up and workings of Meesho’s internal security system and see how simple tweaks create big effects. But first…

Why do need a security scanner in the first place?

When we push a string of code into production there might be:

1. Vulnerable and risky code being pushed into production.
2. Hard-coded secrets, which are often stored in plain text and are easily extractable from the source code.
3. Vulnerabilities arising from the use of dependencies from open sources.

Building a strong security funnel that vets and scans for any vulnerabilities at the source is one way of ensuring that vulnerable code isn’t going out. Now, with the basics established, let’s move on to making a solid security system.

Let’s start building!

Here’s a fact: developers outnumber security engineers by a long margin, and the sheer influx of codes on a daily basis is so big that manual review is technically impossible. So, we needed a solution that was effective, quick and, most importantly, automated.

To this end, we built a security scanner that is triggered into action by GitHub webhooks. The scanner analyses the code for defects and compiles a list of found defects which is delivered via a dashboard.

The flagged code are reworked and sent back into the scanner for vetting and, if cleared, passed into production.

Now, our engineers generate thousands of lines of code each day. This also means that we deal with a slew of diverse vulnerabilities and defects that may arise from different engineering teams, and thus our security scanner must enclose different kind of tools to deal with for all kinds of defects.

After much deliberation, we zeroed in on three tools:

1. Semgrep for Static Application Security Testing (SAST).
2. Dependabot for scanning the code for dependency issues.
3. Trufflehog, an open source tool, that scans source code repositories for Hardcoded secrets and keys.

While we followed standard installation and execution procedure for Trufflehog and Dependabot, we tweaked our SAST tool for improved results. But before we talk about tweaking the SAST tool, let’s understand SAST.

What is SAST?

SAST is a method of scanning source code at rest and flagging vulnerabilities. The other way to scan for security threats is by using DAST — Dynamic Application Security Testing — where the code is analysed for security vulnerabilities while it’s running. More on this in the upcoming blogs.

Now, every company has its own set of internal library, coding guidelines, etc., and also their own set of unique vulnerabilities. Likewise, we too had our set of novel vulnerabilities and threats that needed to be flagged.

Semgrep allowed us to customize its ‘Rule Engine’ to include vulnerabilities that we wanted to weed out. But before we move into customization of the Rule Engine, let’s know the Rule Engine better.

What is a Rule Engine?

The Rule Engine is the brain of a SAST tool. SAST tools, Semgrep in our case, analyses codes based on the rules defined. These rules are basically instructions on how to treat the incoming code (which code to flag, which to let through). This analysis occurs in the Rule Engine.

Most SAST tools come with an inbuilt set of rules called presets. Once the presets are activated, they will actively scan and weed out vulnerable code and submit a list of defects on the dashboard.

For example, a Rule Engine may have OWASP top 10 vulnerabilities defined in the preset, and thus the SAST tool will readily identify and flag those vulnerabilities.

Now, finally, SAST tool customization.

SAST tool customization

Semgrep allows customizations that help companies create their rules based on previously identified issues via manual code review. So, we developed and embedded our own rule configuration into the process.

Our Rule configuration file is basically an extension of our SAST tool which allows us to prioritize queries, customise Rules efficiently, and have a stronger control over the tool.

This is how our security scanner works

Step 1. Triggering Mechanism: We use github webhooks to trigger the the scans. The webhooks is configured to trigger on every Pull Request made on the develop and master branch. The webhook contains all the information about the reponame, branch, commit etc. These details are then used to clone the repo and initiate the scan.

Step 2. Cloning and Scanning: We parse the response from webhook for repo details and initiate the scans. We used Semgrep and truffleHog for detecting source code vulnerabilities and hardcoded secrets, respectively. We pull dependence vulnerabilities found by Depenabot.

Step 3. Uploading to Dashboard: All the scan results are uploaded in their respective engagements, which are mapped with reponame.

Step 4. Posting Scan report on Pull Request Comments: All the scan-related summary is then shared in the comment section of the respective Pull Request, which notifies the owner and the developer.

The outcome

Our customizations gave extremely efficient outcomes:

1. The system triggers every time a branch is getting merged with the development branch or the master branch.
2. We have curated each security rule of the scanner to keep the noise low and only report high-impact and relevant security issues.
3. Commenting on Pull Request (PR) brings clear visibility about the scan and provides easy navigation to the dashboard with an overview of the scan results.
4. Rescan can easily be triggered with the link sent in the Pull Request (PR) comment.
5. Was used in mitigating the Log4j and spring4shell vulnerabilities.

Our automated security system was successfully able to weed out security defects and also offered very handy solutions to monitor and analyse codes going out of the system.

This automation and monitoring gave a lot of breathing space to our security engineers, who are a handful compared to the hundreds of developers pushing out tons of code each day.

Finally, I would like to thanks Rakesh and Siddarth for leading this project and taking the time of their schedule to talk to me about this project.

Also, a giant hug and high-five to Rahul who squeezed out time for this cover image. Rahul, you are a graphic rockstar.

Also, folks, if you like what we do and want to be a part of Meesho, please head over to our careers page and check for relevant openings.

Until next time.