Is our Code at risk of being burgled?
Well, my house was burgled! For Real. It has been two week since this happened and I was the one to find the house all open and empty. SAD.
Now, as a responsible owner, I had the CCTV installed and all hopes were hinged on the evidence to catch the culprit. We had the Police, sniffing dogs, finger print experts all in our home to collect the evidence. The theft was done by professionals and hence very little clues of finger prints. The police collected the DVR box of CCTV and we all waited with baited breath to find the evidence.
Now, when we were called upon by police to update on the recording, I had a surprise. My DVR had stopped backing up for the past year. I felt like digging a hole and putting my head in it for a while. I just could not believe that I had been so causal about something as important as home security. Well, I had more suprises.
We found the footage form nearby building. The burglars could break open the lock in the gate beacuase, the responsible ME had put a clear lock visible to outside of gate. It was an open invitation with all the greenery giving the cover for the act. I wanted to dig a deeper hole now.
The aspect I found in this whole time was that, I did all the aspects of security but without being fully accountable and responsible about it. It was more of formality. Something like, “Yes, lets do a code check before deployment” – Never meant it to keep my code secure.
Security in our code always seems to a pain in A. We tick all the boxes in the checklist before deployment. But, do we really follow the checklist deligently. I would have to say, No!
Our code check should be done by someone out of the project team who should be forthright and evaluate without any liniency. Maybe, have externals for this purpose.. Why Not?
The simple aspect of unused variables need to be removed without fail. Ensure the ESLINT check of the code results are addressed by removing all the errors which are due to syntax errors by the developer. Infact, one of the parameter before deployment should be limited to a acceptable threshold of errors. The governance team should come to an understanding with the acceptable limit and communicate it to the Developers in the teams.
Our code practices should follow the fundamentals of programming – Immutability, reusability, modular programming, pure functions and so on. The evaluation should also be about all these aspects. The Check for code should involve eliminating “callback hell”.
We should not wait for the hack or break-in or the crash to find the loopholes in our applications. Plugging holes after the horses are gone, again is a formality.
Security is on par with the other key parts of the application development. Without Security applied deligently, we are just having an open invite. Sooner or later, someone will acept the invite for us to dig a deep hole for ourselves and our team.
Note: If my personal story was a bore, forgive me. I am still unable to see myself for being such a Fool. Tis blog a way of me “Coming out” 🙁
P.S. The views expressed in this blog is purely personal.