.jpeg)
Introduction
Imagine this: You’ve just finished building your dream house. It’s beautiful, modern, everything you’ve ever wanted. But then, as you’re about to move in, you realize — oh no, there are no locks on the doors. Now, instead of enjoying your new home, you’re stuck trying to retrofit security into something that wasn’t designed with it in mind.
Sounds crazy, right? Well, guess what — that’s exactly how a lot of software gets built today. We focus so much on making things work and look good that we forget to lock the doors. And when bad guys come knocking (and trust me, they will), we’re left scrambling to fix the mess.
This is something I’ve thought about a lot. With my background in IT and software security — yep, I even have a Master’s degree in it — I’ve spent years studying how vulnerabilities happen and how we can stop them before they cause trouble. What I’ve learned is simple: Security isn’t something you tack on at the end. It’s something you build in from the start.
The Evolution of Secure Software Development
Let’s rewind a bit. Back in the early 2000s, Microsoft was getting hammered for all the security flaws in its products. People were frustrated, and Microsoft knew they had to do something. So, Bill Gates sent out a memo to his teams saying, “Hey, from now on, trustworthy computing is our top priority.” That memo led to the creation of the Security Development Lifecycle (SDL) — a process that made security a core part of every step of software development.
And guess what? It worked. Over time, Microsoft not only reduced the number of vulnerabilities in its products but also set a new standard for secure software development. Even Linux, which has always been seen as super secure, struggled to keep up. The lesson here? If you bake security into your process from the beginning, you save yourself a ton of headaches later.
Modern Approaches to Security in Development
So, how do we make sure security is part of the process? Let me break it down for you.
1. The Three Pillars of Software Security
There are three main ways we test software for vulnerabilities:
Static Analysis: This is like proofreading your code before it goes live. You check for mistakes while the code is still sitting there, untouched.
Dynamic Analysis: This happens when the code is running. It’s like watching someone use your app in real-time and seeing if anything breaks or looks suspicious.
Hybrid Analysis: This combines the best of both worlds — static and dynamic testing — to give you a complete picture of your software’s security.
But tools alone won’t cut it. What really matters is the mindset. When you’re writing code, you need to think, “How could someone misuse this?” That’s what we call Secure by Design—building security into the DNA of your software.
2. SecDevOps: Making Security Everyone’s Job
Now, let’s talk about DevOps. If you’re not familiar with it, don’t worry — it’s just a fancy way of saying, “We’re going to build, test, and release software faster.” But here’s the problem: In traditional DevOps, security often gets left behind. Developers are racing to push features out the door, and security becomes an afterthought.
That’s why we have DevSecOps — where security is integrated into the DevOps process. Some people even prefer the term SecDevOps, which flips the order to show that security comes first. I like this idea because it reminds us that security isn’t just one team’s job — it’s everyone’s responsibility.
To make this work, we focus on two key practices, on top of CI/CD:
Continuous Testing: Running security checks at every stage of development, not just at the end.
Continuous Security: Keeping an eye on security throughout the entire lifecycle of the software.
By shifting security “left” (earlier in the process), we catch problems before they become big, expensive disasters.
Balancing Security and Business Demands
Here’s the tricky part: Developers are under pressure to deliver features fast. Businesses want results yesterday. But if we rush too much, we risk leaving the doors wide open for attackers. So, how do we find the balance?
It comes down to risk management. Instead of trying to fix every single issue, we focus on the biggest risks first. For example, if a vulnerability could expose customer data, that’s a top priority. If it’s something minor, maybe we can address it later.
The goal is to move fast without breaking things. Security shouldn’t slow you down — it should help you go faster by preventing costly mistakes.
Conclusion: Secure First, Deploy Smart
Here’s the bottom line: Security isn’t something you can slap on at the end — it has to be built in from the start. Whether your team is using Agile methodologies, adopting SecDevOps, leveraging program analysis tools, or following frameworks like Microsoft’s Security Development Lifecycle (SDL), the key is simple: Ensure it’s secure by design.
Think of it this way — no matter what tools or processes you use, they’re only as effective as the mindset behind them. If security is treated as an afterthought, even the best tools won’t save you. But if you embed security into every step of your process — whether you’re writing code, running tests, or deploying features—you’re setting yourself up for success.
So, here’s my challenge to you: How is your organization ensuring Secure by Design? Are you integrating it into your Agile sprints? Are you shifting security left in your SecDevOps pipeline? Or are you relying on static and dynamic analysis to catch vulnerabilities early? Whatever your approach, the goal is the same: Build software that’s secure from the ground up.
Because when it comes to security, we’re all in this together.
#CyberSecurity #SecureByDesign #DevSecOps #SecDevOps #SoftwareDevelopment #RiskManagement
1
1
2You can easily set up a man in the middle attack to circumvent https for example. This is one of the reasons you shouldn't rely on https keeping your data secure when using a public WiFi network.
Johan
2
1Yes. For example, I've done a man in the middle attack that could easily be implemented in a place like Starbucks to intercept banking (or any other SSL encrypted info).
Disclaimer: this was part of a demonstration, with permission, and fully legal.
Johan.
2
1Have a look at some of the security issues, both older versions and current ones:
http://en.wikipedia.org/wiki/Transport_Layer_Security#Security
One quote: "As of March 2013, an estimated 65.7% of web sites were supporting protocol variants vulnerable to the BEAST attack, 30.0% vulnerable to the CRIME attack, and 34.2% with insecure ciphers."
Johan.
If you are using it to protect highly secret stuff then you should know what you are doing and force the use of the latest versions at both ends as well as forcing the use of a strong cipher suite. In this scenario HTTPS is probably as strong as any other crypto protocol.
If you are using it in relatively lower security applications, then the weaknesses pointed out in this discussion are often not an issue because they are not worth the attack effort. These attacks generally require special circumstances and often many, many, sessions before they become practical. Even if successful, the attack might not actually be significant in your application.
WRT people ignoring warnings about bad certificates, etc. - It is the browser that is allowing the user a choice of connecting to a dodgy website, and the user for ignoring the warnings. This cannot really be blamed on HTTPS.
Of course there is always going to be bad implementations, bad configurations etc. I blame these mainly on service providers who are not responsible enough with their user’s security, not on HTTPS.
2
1http://www.schneier.com/paper-ssl-revised.pdf
SSL/TLS has withstood the test of time (the greatest test of any cryptosystem). No other crypto protocol has been subjected to anywhere near the same amount of scrutiny and attack. Warts and all, it is the Godzilla of all crypto protocols.
Probably the most popular cipher suite - TLS_RSA_WITH_RC4_128_SHA (not affected by “Beast” and “Crime”) has protected very many online bank accounts for nearly 2 decades. Regardless of the weaknesses in RC4, there has still been no reported attack where money was stolen due to its breaking. In fact, even if an attack was able to reveal the plaintext, the attacker could still not steal your money because the HMAC prevents modification.
IMHO it is better to fix HTTPS whenever a weakness is revealed and move on rather than introduce a completely new protocol as this would put us right back to the beginning e.g. unproven.
my post was precisely intended to show that even if HTTPS has some (minor) issues, they can be easily managed, as Bruce Schneier, a guru of cryptography, clearly explains in the paper.
From my point of view, apart from human factors, the real problem involves back compatibility constraints, due to the fact that not all browsers implement SSL/HTTPS correctly/completely, nor even care to take advantage of newer security features exposed by the protocol, as soon as they become available.