Every Line of Code is a Potential Bug

How to reduce the chances of a security flaw in your application with the principle of abstraction

One of my post that may later become a book on Secure Code. Also one of my posts on Application Security.

Free Content on Jobs in Cybersecurity | Sign up for the Email List

Sometimes I write a finding on a cloud and web application penetration test and then later realize that I need to be more specific about the finding I’ve described and how to fix it. The principles I use when writing software seem obvious to me, but I’ve been doing it so long. I have to remember that what is clear in my mind may not be so in the mind of others. I learn how to provide better information each time I deliver a report because of the questions clients ask me about the findings. Recent experiences led me to this series of posts.

As I was thinking about this new series, a security incident occurred related to some open-source software: faker.js and colors.js. This problem fits nicely into some of the things I was planning to write about anyway, so I’ll probably expand on that in a future post. I just found colors.js on a recent customer penetration test. I always research the included libraries in customer applications and provide guidance related to those…