Newsletters I subscribe to

  • O’Reilly Newsletters – A collection of weekly newsletters covering topics ranging from Programing, Data, AI, Infrastructure, Operations to Economy and more.

  • Meanwhile in Security – Cloud Security For Humans. Meanwhile in Security cuts through the standard bullshit, gatekeeping, and fearmongering pervasive in infosec circles. Ain’t nobody got time for that crap. It’s also available as a podcast.

  • tl;dr sec Newsletter – The best way to keep up with the latest and greatest in information security.

  • The Cloud Security Reading List – A low volume newsletter (delivered once per week) that highlights security-related news focused on the cloud native landscape

  • The Hustle – Business and tech in 5 minutes or less

Counter Strike: Global Offensive on macOS

I have been playing Counter Strike: Global Offensive on MacBook Pro (Retina, 15-inch, Mid 2015) with around 80 FPS. Here is the guide on how to set it up.

You can download free version of Counter Strike: Global Offensive from steam store –

Once installed, go to launch options by right clicking on the game name -> properties -> Set launch options.

Paste following launch options:

-novid -high -threads 8 +fps_max 0 -freq 60 -refresh 60 +cl_forcepreload 1 -nod3d9ex -nojoy

For better FPS, you can have the following video settings:



Getting started with React and Redux

I have been learning React and Redux for some time now. Here is the collection of reading material / video courses I found useful.

Video courses

​Reading on React / Redux



Here are some high quality newsletters you should subscribe for your weekly webdev news:


Please comment with the links you have found useful for learning React / Redux.

Introduction to security vulnerabilities

Here is my presentation on “Introduction to security vulnerabilities” given at VodQA Shots, Hyderabad. The theme for the conference was “Security: Towards a safer web world”.


This presentation was accompanied by demo of an application vulnerableto XSS and SQL Injection. The code can be found at this Github repository.

Recommended reading – Developers interview at ThoughtWorks

This post has now been moved to and updated at –

I have been helping with recruitment in ThoughtWorks for quite some time now. Based on my experiences of interviewing developers, following are some links I would recommend everybody should go, or have just skim through while appearing for an interview at ThoughtWorks.

Note: This is not a exclusive list by any means. I have tried to keep this list as programming language agnostic as I can. All of the points mentioned below are absolute basic knowledge to have. Advanced topics are usually covered in the interview based on the experience and expertise of the candidate.

About ThoughtWorks

Object Oriented Modeling and Design

Data Structures

Programming general

Clean code and Refactoring

Computer Networks

Software Engineering / Agile

Agile vs Waterfall

Agile Practices

Test Driven Development (TDD)

Extreme Programming (XP)

Pair Programming

Useful blogs to follow


Application Security: The Agile Way

Agile showed a great way of building projects in an iterative fashion. Benefits of using Agile processes over waterfalls are evident.

However, even though agile projects have existed for years, the approach to security on these projects has remained the same as waterfall. Security testing / penetration testing is still big bang, just a week before release of the project.

There are some fundamental problems with the existing “waterfallish” approach to application security. Some of them are:

  • Penetration testing very close to release, leads the developers and business finding workarounds for the vulnerabilities in a rush instead of patching them properly. This often leads to multiple unpatched vulnerabilities in long run. Also, there is a possibility of the workaround for one vulnerability making another component vulnerable.
  • Sometimes security problems are result of the architectural decisions. For example, sending the current user password in plain text for “Forgot password” functionality. By the time these security vulnerabilities are uncovered, it might be too late to change the architecture.
  • If the components / dependencies used (for example, libraries) have known vulnerabilities, it might be difficult to change them just before the project release.

Problems such as the ones mentioned above poses a very important question. What would it take to do application security the “agile way”?

In order to answer this question, the following points seemed imperative.


Developers who knows how to write “secure code”

Most of the security problems would be avoided if developers know and write secure code. Every time developers write code to accept user input, they should think about validation. Every time they needs to store customer data into database, they should think about the sensitivity of the data and the need of encryption.

Knowing about OWASP Top 10 vulnerabilities is a must. And then there are some great resources for developers to learn about secure coding practices. My favorites are:


“Security expert” on the project

Let’s agree that no matter how much a developer tries to learn about secure coding practices, there will always be something in the code which only an experienced eyes can catch. Hence, it is advisable for each team to have at least one designated security expert who is reasonably experienced in the field of application security. The required experience level can vary based on the complexity and the number and type of “sensitive points” of the system, but the more experienced the security expert, the better.

Usually the role of security expert includes:

  • Pairing with other developers on developing security sensitive stories.
  • Uncovering and conveying different ways to break the system to the developers. This also means fixing the problems before the code is even checked-in into version control system.
  • Taking part in the discussions on choosing libraries to use, deciding contracts with external systems, deciding public APIs, etc.
  • Helping Quality Analysts to test security sensitive stories.

In addition to these tasks, the security expert is also expected to help in building secure code writing practices and security testing capabilities with the team.


“Security Sensitive” stories

In Iteration Planning Meeting, at the beginning of the each iteration, security expert (with the team) should mark stories involving security related design and decisions as “security sensitive”. Some sample scenarios in a story that must be marked as security sensitive are:

  • Introducing a new user input field (text, dropdown, etc.)
  • Storing user input to database
  • Invoking external processes or system commands
  • Processing data received from external system
  • Dealing with authentication and authorization process


Abuse cases for each security sensitive story

Every story has acceptance criteria. For security sensitive stories Business Analyst (with the help of security expert) should write acceptance criteria from security point of view. Similar to Use Cases, Security expert is expected to write abuse cases around the functionality. This ultimately helps Quality Analysts to write test cases from security testing point of view.


Security testing before a story is “accepted by business”

When a security sensitive story moves to “in testing”, Quality Analysts must test the story for abuse cases to check expected system behavior. Security specialist can help Quality Analyst in this. Of course, this testing has to be done along with functional testing of the story. If a vulnerability is found during the testing, the story must be moved back to “ready for development”. Then developer fixes the vulnerability properly and moves the story again in the “ready for testing” lane. And the cycle continues. Once story is tested for all the functionality and no vulnerability and loss of functionality is reported, the story can be moved to “accepted by business” status.


Automation or no automation?

Automation of security testing is a very controversial point of discussion in the field of security. Some believe there is no replacement for human testing, whereas some believe there should be a full automation for testing.

I personally believe that there is a middle ground. Of course we need a security tester to find the vulnerabilities in the system. But once found, security testers should write automated test so that they will never need to test for the same vulnerability again in the same part of the system. Tools like OWASP Zed Attack Proxy can be helpful in writing such automated tests.



It goes without saying that we should build security into the application than around the application. Using the pointers above, we were able to successfully deliver relatively more secure system. We did have a “conventional” big bang penetration testing just before the project went live. But as expected, we did not have any high (or even medium) priority vulnerabilities reported in the system.

From the customer’s point of view, this process gave them a high confidence in the security of the system. A major point to note was that, there was no deadline slippage because of the security issues.

Finally, there is no silver bullet which can be applied to all projects. The whole point of being agile is that, it gives us opportunity to change or modify the approach which is best suited for the system under development. This post can be considered as a pointer on what is the minimum we can do in to bake security into the system being developed in agile way.

Find subdomains of a domain name

I often needed to find sub-domains of a domain. Simple Google search for any tool doesn’t return any good results. There are couple of command line tools which does some brute forcing. But they are painfully slow.

I found another easier way to do this using Wolfram Alpha.

  1. Visit
  2. Search for the domain you want sub-domains of. For example,
  3. Click on “Subdomains” tab in web statistics section.
    Subdomain link on WolframAlpha
  4. Wolfram Alpha will list of known sub-domains of the domain
    List of sub domain names

Of course, it might not list all the sub-domains, but this should be a good enough starting point without going to the command line. 🙂

Download videos from InfoQ

InfoQ has amazing collection of presentations from different conferences. I love to watch these videos.

The problem I have is I don’t really have a high speed Internet connection at home. Thankfully, my employer ThoughtWorks has very high speed Internet line in office. So, downloading video in office and watching it at home seems like a very good option.

InfoQ doesn’t have a download button as such for these presentations. Somebody has written python script for this. But I wasn’t able to install bs4 package on my Mac. 😦
So, I created a small shell script for my own to get the URL of the video. 🙂

#! /bin/bash
# Author: Shirish Padalkar (
if [ "$#" -ne 1 ]; then
echo "Usage: $0 infoq_presentation_url"
exit 1
url_with_spaces=`curl -A "Mozilla/5.0 (iPad; U; CPU OS 3_2 like Mac OS X; en-us) AppleWebKit/531.21.10 (KHTML, like Gecko) Version/4.0.4 Mobile/7B334b Safari/531.21.10" $1 | grep "<source src=" | tr -dc "[:print:]"`
url=${url_with_spaces//<source src=/}
echo "You can download this video from ${url// \/>/}"

view raw

hosted with ❤ by GitHub

This script is no way perfect. And yes, I know it’s a very dirty code. 😉


Custom shell commands with wildcard characters in Go CI

For your build pipeline, ThoughtWork’s GO let you define tasks to invoke a shell command or script. This is extremely useful for tasks such as ssh’ing or scp’ing files to deployment servers.

For this post, we will take example of SCP.

You can setup task to scp a single file as shown in following screenshot:

For single file uploads, this work perfectly fine. But if you want to upload multiple files (for example, all zip files in the folder), you would like to specify it with shell wildcard characters like * or ?.

Unfortunately, this does not work. We get following error with above settings:

dist/*.zip: No such file or directory

The problem here is Go internally puts all parameters inside single quotes(‘) while executing command. So, even if you intended the command to run as

scp dist/*.zip

the actual command which gets executed is

scp 'dist/*.zip' ''

As the parameter is inside single quote, shell will not try to interpolate the wildcard character * in the command.

To overcome this limitation, you can use bash’s


switch. This bash switch lets you specify a string which will executed in a shell’s context.

After specifying above settings, you can achieve the intended results.