Starting "left of left": Is secure code always quality code?
A version of this article appeared in Dark Reading. It has been updated and syndicated here.
When talking to developers about security, one of my mantras is that “the only quality code is secure code”. This remains true; we might have escaped disaster when vulnerable software was out in the wild in the 90s, but it’s not worth the risk today. Many have worked hard to instill a security-aware mindset in developers over the years, and in doing so, have hopefully made security synonymous with quality when it comes to a self-assessment of their code.
Upon reflection (and some debate among my peers), however, it’s perhaps oversimplifying the concept. It is entirely possible to create code that is indeed secure, yet shows signs of novice development technique, or other problem areas that render it less than ideal.
Our industry talks at length about the notion of “shifting left”. In my mind, it’s all about “starting” left by enabling engineering cohorts to share the responsibility for security (being an aspect of quality), and giving them the power to erase common vulnerabilities at their (literal) fingertips. In light of this current conundrum, though, it seems the envelope must be pushed a little further.
Code of a certain level of quality is by its definition also secure, but all secure code is not necessarily good quality. Is starting “left of left” the formula to ensure pure secure coding standards?
What does “poor quality” secure code look like?
Let’s get the magnifying glass over this code snippet:
If we analyze this code from a security perspective, this snippet is indeed secure, and not an entry point for an attacker to exploit a SQL Injection vulnerability.
Is it an example of high-quality code? Not really, unfortunately. A simple change to the argument from an int(eger) to a String value allows free-form user input to manipulate the query, in contrast to a number which cannot. That change -- or a haphazard copy and paste of the String sql from somewhere else -- immediately creates an environment where SQL injection vulnerabilities are possible, and all the risks associated with them:
The security measures had a very limited scope here, whereas a more thorough (or, experienced) developer may have taken a different approach and considered implications of inefficient argument structure. Shipping code like this is not only poor practice, it sets a bad example for others in the development cohort.
The software “triple threat”: Form, function, fortress-like?
A “triple threat” in the entertainment industry is an individual who can act, dance, and sing with an equally high level of skill. They are the people feared and envied at every audition, and are the unicorns of an already competitive space. Every industry has its own version of a top-tier, exceptional example of its products and services, with software being no exception.
If we think of three key elements in applications that are difficult to balance with equal (high) quality, they might be functionality/elegance, plus iron-clad security, plus cost-effectiveness when considering the required speed of delivery. Now, that last attribute is undoubtedly a defining factor in how well the other two options are applied, and it can be a catalyst for overall quality slipping over time.
However, does all software need to perform like Hugh Jackman, or can we get away with Nicolas Cage? Put it this way: if you can get Wolverine on your team, then you give it your best shot.
Martin Fowler asked the question, Is High Quality Worth The Cost? in software development, concluding that not only was it “worth it”, but it was actually cheaper over time. Most users aren’t going to be looking under the hood to assess whether the code is a mess, nor whether security was made just as important everything else. However, those on the tools will waste precious time redoing sloppy code to add on newer features, or trawling through major parts of the project to understand what’s going on, or, the worst-case scenario: fixing a vulnerability that has bounced back from the AppSec team and delayed production. Spending time now to make code both secure and good quality saves a lot of future heartaches, not to mention the cost of unraveling poorly executed work.
Skilled security-aware developers write code that retains their creative, problem-solving vision in feature delivery, with consideration given to erasing the common security pitfalls that engineers can control in their stage of the process. Secure code isn’t terribly effective in isolation, and that is why the notion of starting “left of left” will help support a culture of security as second nature for developers, built into their capacity to deliver amazing features with reduced risk.
Starting “left of left” is critical for secure user experience.
Security has been a consideration in the software user experience for a long time, yet clearly resulted in mixed success. Security misconfigurations accounted for 21% of cloud-based data breaches in the past year, with amateur-hour errors like storing passwords in plaintext resulting in some serious losses in productivity, revenue, and customer trust for affected companies.
That, and users themselves can be their own worst enemy when it comes to protecting their own data. Far too many people are still using “password” as their password, or using the same combination across multiple sensitive accounts.
I don’t know any developers who fist-pump the air when they’re told they have to work on a login screen, and it’s no wonder: it’s a delicate balance to design a security flow that is robust, functional, and that users will be able to navigate in a way that makes sense to them, with the least disruption.
Put in too many complex steps and restrictions, and users may switch off never to return (a disaster for a new app), make it too confusing, and you might end up giving the support team a collective migraine as they field queries from users trying to access their accounts. Make it too easy, and you’re kind of failing at the security part.
A successful secure user experience needs to weave tight security into a flow that makes sense, presented in a way that doesn’t detract from everything else that is compelling about the software. You can certainly meet the objective of coding a secure login function, putting in all manner of complex password requirements, CAPTCHA, mini-bosses, and four waves of zombies, but if it’s a total mess that is repellant to users, it’s missing the mark.
Lay the foundation for software excellence.
As a developer myself, I know that the vast majority of us take pride in our work, and want to do the right thing. Pesky curveballs like time constraints, sudden changes in the current objective, or urgent hotfixes can disrupt the flow and lead to mistakes, but the harsh truth is that many software engineers are not set up for success.
Starting “left of left” is a developer-first concept, and requires organizations to get serious about uplifting their engineering cohort. Security-aware developers are worth their weight in gold, and support in the form of training, provision of the right tools, and the opportunity to be mentored by more experienced developers will foster an environment where code is crafted with a security-first mindset, with the precision and attention to detail required to take software to the next level.
Ready to ignite the secure coding fire in yourself? Rise to the challenge.
Code of a certain level of quality is by its definition also secure, but all secure code is not necessarily good quality. Is starting “left of left” the formula to ensure pure secure coding standards?
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
A version of this article appeared in Dark Reading. It has been updated and syndicated here.
When talking to developers about security, one of my mantras is that “the only quality code is secure code”. This remains true; we might have escaped disaster when vulnerable software was out in the wild in the 90s, but it’s not worth the risk today. Many have worked hard to instill a security-aware mindset in developers over the years, and in doing so, have hopefully made security synonymous with quality when it comes to a self-assessment of their code.
Upon reflection (and some debate among my peers), however, it’s perhaps oversimplifying the concept. It is entirely possible to create code that is indeed secure, yet shows signs of novice development technique, or other problem areas that render it less than ideal.
Our industry talks at length about the notion of “shifting left”. In my mind, it’s all about “starting” left by enabling engineering cohorts to share the responsibility for security (being an aspect of quality), and giving them the power to erase common vulnerabilities at their (literal) fingertips. In light of this current conundrum, though, it seems the envelope must be pushed a little further.
Code of a certain level of quality is by its definition also secure, but all secure code is not necessarily good quality. Is starting “left of left” the formula to ensure pure secure coding standards?
What does “poor quality” secure code look like?
Let’s get the magnifying glass over this code snippet:
If we analyze this code from a security perspective, this snippet is indeed secure, and not an entry point for an attacker to exploit a SQL Injection vulnerability.
Is it an example of high-quality code? Not really, unfortunately. A simple change to the argument from an int(eger) to a String value allows free-form user input to manipulate the query, in contrast to a number which cannot. That change -- or a haphazard copy and paste of the String sql from somewhere else -- immediately creates an environment where SQL injection vulnerabilities are possible, and all the risks associated with them:
The security measures had a very limited scope here, whereas a more thorough (or, experienced) developer may have taken a different approach and considered implications of inefficient argument structure. Shipping code like this is not only poor practice, it sets a bad example for others in the development cohort.
The software “triple threat”: Form, function, fortress-like?
A “triple threat” in the entertainment industry is an individual who can act, dance, and sing with an equally high level of skill. They are the people feared and envied at every audition, and are the unicorns of an already competitive space. Every industry has its own version of a top-tier, exceptional example of its products and services, with software being no exception.
If we think of three key elements in applications that are difficult to balance with equal (high) quality, they might be functionality/elegance, plus iron-clad security, plus cost-effectiveness when considering the required speed of delivery. Now, that last attribute is undoubtedly a defining factor in how well the other two options are applied, and it can be a catalyst for overall quality slipping over time.
However, does all software need to perform like Hugh Jackman, or can we get away with Nicolas Cage? Put it this way: if you can get Wolverine on your team, then you give it your best shot.
Martin Fowler asked the question, Is High Quality Worth The Cost? in software development, concluding that not only was it “worth it”, but it was actually cheaper over time. Most users aren’t going to be looking under the hood to assess whether the code is a mess, nor whether security was made just as important everything else. However, those on the tools will waste precious time redoing sloppy code to add on newer features, or trawling through major parts of the project to understand what’s going on, or, the worst-case scenario: fixing a vulnerability that has bounced back from the AppSec team and delayed production. Spending time now to make code both secure and good quality saves a lot of future heartaches, not to mention the cost of unraveling poorly executed work.
Skilled security-aware developers write code that retains their creative, problem-solving vision in feature delivery, with consideration given to erasing the common security pitfalls that engineers can control in their stage of the process. Secure code isn’t terribly effective in isolation, and that is why the notion of starting “left of left” will help support a culture of security as second nature for developers, built into their capacity to deliver amazing features with reduced risk.
Starting “left of left” is critical for secure user experience.
Security has been a consideration in the software user experience for a long time, yet clearly resulted in mixed success. Security misconfigurations accounted for 21% of cloud-based data breaches in the past year, with amateur-hour errors like storing passwords in plaintext resulting in some serious losses in productivity, revenue, and customer trust for affected companies.
That, and users themselves can be their own worst enemy when it comes to protecting their own data. Far too many people are still using “password” as their password, or using the same combination across multiple sensitive accounts.
I don’t know any developers who fist-pump the air when they’re told they have to work on a login screen, and it’s no wonder: it’s a delicate balance to design a security flow that is robust, functional, and that users will be able to navigate in a way that makes sense to them, with the least disruption.
Put in too many complex steps and restrictions, and users may switch off never to return (a disaster for a new app), make it too confusing, and you might end up giving the support team a collective migraine as they field queries from users trying to access their accounts. Make it too easy, and you’re kind of failing at the security part.
A successful secure user experience needs to weave tight security into a flow that makes sense, presented in a way that doesn’t detract from everything else that is compelling about the software. You can certainly meet the objective of coding a secure login function, putting in all manner of complex password requirements, CAPTCHA, mini-bosses, and four waves of zombies, but if it’s a total mess that is repellant to users, it’s missing the mark.
Lay the foundation for software excellence.
As a developer myself, I know that the vast majority of us take pride in our work, and want to do the right thing. Pesky curveballs like time constraints, sudden changes in the current objective, or urgent hotfixes can disrupt the flow and lead to mistakes, but the harsh truth is that many software engineers are not set up for success.
Starting “left of left” is a developer-first concept, and requires organizations to get serious about uplifting their engineering cohort. Security-aware developers are worth their weight in gold, and support in the form of training, provision of the right tools, and the opportunity to be mentored by more experienced developers will foster an environment where code is crafted with a security-first mindset, with the precision and attention to detail required to take software to the next level.
Ready to ignite the secure coding fire in yourself? Rise to the challenge.
A version of this article appeared in Dark Reading. It has been updated and syndicated here.
When talking to developers about security, one of my mantras is that “the only quality code is secure code”. This remains true; we might have escaped disaster when vulnerable software was out in the wild in the 90s, but it’s not worth the risk today. Many have worked hard to instill a security-aware mindset in developers over the years, and in doing so, have hopefully made security synonymous with quality when it comes to a self-assessment of their code.
Upon reflection (and some debate among my peers), however, it’s perhaps oversimplifying the concept. It is entirely possible to create code that is indeed secure, yet shows signs of novice development technique, or other problem areas that render it less than ideal.
Our industry talks at length about the notion of “shifting left”. In my mind, it’s all about “starting” left by enabling engineering cohorts to share the responsibility for security (being an aspect of quality), and giving them the power to erase common vulnerabilities at their (literal) fingertips. In light of this current conundrum, though, it seems the envelope must be pushed a little further.
Code of a certain level of quality is by its definition also secure, but all secure code is not necessarily good quality. Is starting “left of left” the formula to ensure pure secure coding standards?
What does “poor quality” secure code look like?
Let’s get the magnifying glass over this code snippet:
If we analyze this code from a security perspective, this snippet is indeed secure, and not an entry point for an attacker to exploit a SQL Injection vulnerability.
Is it an example of high-quality code? Not really, unfortunately. A simple change to the argument from an int(eger) to a String value allows free-form user input to manipulate the query, in contrast to a number which cannot. That change -- or a haphazard copy and paste of the String sql from somewhere else -- immediately creates an environment where SQL injection vulnerabilities are possible, and all the risks associated with them:
The security measures had a very limited scope here, whereas a more thorough (or, experienced) developer may have taken a different approach and considered implications of inefficient argument structure. Shipping code like this is not only poor practice, it sets a bad example for others in the development cohort.
The software “triple threat”: Form, function, fortress-like?
A “triple threat” in the entertainment industry is an individual who can act, dance, and sing with an equally high level of skill. They are the people feared and envied at every audition, and are the unicorns of an already competitive space. Every industry has its own version of a top-tier, exceptional example of its products and services, with software being no exception.
If we think of three key elements in applications that are difficult to balance with equal (high) quality, they might be functionality/elegance, plus iron-clad security, plus cost-effectiveness when considering the required speed of delivery. Now, that last attribute is undoubtedly a defining factor in how well the other two options are applied, and it can be a catalyst for overall quality slipping over time.
However, does all software need to perform like Hugh Jackman, or can we get away with Nicolas Cage? Put it this way: if you can get Wolverine on your team, then you give it your best shot.
Martin Fowler asked the question, Is High Quality Worth The Cost? in software development, concluding that not only was it “worth it”, but it was actually cheaper over time. Most users aren’t going to be looking under the hood to assess whether the code is a mess, nor whether security was made just as important everything else. However, those on the tools will waste precious time redoing sloppy code to add on newer features, or trawling through major parts of the project to understand what’s going on, or, the worst-case scenario: fixing a vulnerability that has bounced back from the AppSec team and delayed production. Spending time now to make code both secure and good quality saves a lot of future heartaches, not to mention the cost of unraveling poorly executed work.
Skilled security-aware developers write code that retains their creative, problem-solving vision in feature delivery, with consideration given to erasing the common security pitfalls that engineers can control in their stage of the process. Secure code isn’t terribly effective in isolation, and that is why the notion of starting “left of left” will help support a culture of security as second nature for developers, built into their capacity to deliver amazing features with reduced risk.
Starting “left of left” is critical for secure user experience.
Security has been a consideration in the software user experience for a long time, yet clearly resulted in mixed success. Security misconfigurations accounted for 21% of cloud-based data breaches in the past year, with amateur-hour errors like storing passwords in plaintext resulting in some serious losses in productivity, revenue, and customer trust for affected companies.
That, and users themselves can be their own worst enemy when it comes to protecting their own data. Far too many people are still using “password” as their password, or using the same combination across multiple sensitive accounts.
I don’t know any developers who fist-pump the air when they’re told they have to work on a login screen, and it’s no wonder: it’s a delicate balance to design a security flow that is robust, functional, and that users will be able to navigate in a way that makes sense to them, with the least disruption.
Put in too many complex steps and restrictions, and users may switch off never to return (a disaster for a new app), make it too confusing, and you might end up giving the support team a collective migraine as they field queries from users trying to access their accounts. Make it too easy, and you’re kind of failing at the security part.
A successful secure user experience needs to weave tight security into a flow that makes sense, presented in a way that doesn’t detract from everything else that is compelling about the software. You can certainly meet the objective of coding a secure login function, putting in all manner of complex password requirements, CAPTCHA, mini-bosses, and four waves of zombies, but if it’s a total mess that is repellant to users, it’s missing the mark.
Lay the foundation for software excellence.
As a developer myself, I know that the vast majority of us take pride in our work, and want to do the right thing. Pesky curveballs like time constraints, sudden changes in the current objective, or urgent hotfixes can disrupt the flow and lead to mistakes, but the harsh truth is that many software engineers are not set up for success.
Starting “left of left” is a developer-first concept, and requires organizations to get serious about uplifting their engineering cohort. Security-aware developers are worth their weight in gold, and support in the form of training, provision of the right tools, and the opportunity to be mentored by more experienced developers will foster an environment where code is crafted with a security-first mindset, with the precision and attention to detail required to take software to the next level.
Ready to ignite the secure coding fire in yourself? Rise to the challenge.
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Click on the link below and download the PDF of this one pager.
DownloadSecure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
View reportBook a demoMatias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.
Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.
A version of this article appeared in Dark Reading. It has been updated and syndicated here.
When talking to developers about security, one of my mantras is that “the only quality code is secure code”. This remains true; we might have escaped disaster when vulnerable software was out in the wild in the 90s, but it’s not worth the risk today. Many have worked hard to instill a security-aware mindset in developers over the years, and in doing so, have hopefully made security synonymous with quality when it comes to a self-assessment of their code.
Upon reflection (and some debate among my peers), however, it’s perhaps oversimplifying the concept. It is entirely possible to create code that is indeed secure, yet shows signs of novice development technique, or other problem areas that render it less than ideal.
Our industry talks at length about the notion of “shifting left”. In my mind, it’s all about “starting” left by enabling engineering cohorts to share the responsibility for security (being an aspect of quality), and giving them the power to erase common vulnerabilities at their (literal) fingertips. In light of this current conundrum, though, it seems the envelope must be pushed a little further.
Code of a certain level of quality is by its definition also secure, but all secure code is not necessarily good quality. Is starting “left of left” the formula to ensure pure secure coding standards?
What does “poor quality” secure code look like?
Let’s get the magnifying glass over this code snippet:
If we analyze this code from a security perspective, this snippet is indeed secure, and not an entry point for an attacker to exploit a SQL Injection vulnerability.
Is it an example of high-quality code? Not really, unfortunately. A simple change to the argument from an int(eger) to a String value allows free-form user input to manipulate the query, in contrast to a number which cannot. That change -- or a haphazard copy and paste of the String sql from somewhere else -- immediately creates an environment where SQL injection vulnerabilities are possible, and all the risks associated with them:
The security measures had a very limited scope here, whereas a more thorough (or, experienced) developer may have taken a different approach and considered implications of inefficient argument structure. Shipping code like this is not only poor practice, it sets a bad example for others in the development cohort.
The software “triple threat”: Form, function, fortress-like?
A “triple threat” in the entertainment industry is an individual who can act, dance, and sing with an equally high level of skill. They are the people feared and envied at every audition, and are the unicorns of an already competitive space. Every industry has its own version of a top-tier, exceptional example of its products and services, with software being no exception.
If we think of three key elements in applications that are difficult to balance with equal (high) quality, they might be functionality/elegance, plus iron-clad security, plus cost-effectiveness when considering the required speed of delivery. Now, that last attribute is undoubtedly a defining factor in how well the other two options are applied, and it can be a catalyst for overall quality slipping over time.
However, does all software need to perform like Hugh Jackman, or can we get away with Nicolas Cage? Put it this way: if you can get Wolverine on your team, then you give it your best shot.
Martin Fowler asked the question, Is High Quality Worth The Cost? in software development, concluding that not only was it “worth it”, but it was actually cheaper over time. Most users aren’t going to be looking under the hood to assess whether the code is a mess, nor whether security was made just as important everything else. However, those on the tools will waste precious time redoing sloppy code to add on newer features, or trawling through major parts of the project to understand what’s going on, or, the worst-case scenario: fixing a vulnerability that has bounced back from the AppSec team and delayed production. Spending time now to make code both secure and good quality saves a lot of future heartaches, not to mention the cost of unraveling poorly executed work.
Skilled security-aware developers write code that retains their creative, problem-solving vision in feature delivery, with consideration given to erasing the common security pitfalls that engineers can control in their stage of the process. Secure code isn’t terribly effective in isolation, and that is why the notion of starting “left of left” will help support a culture of security as second nature for developers, built into their capacity to deliver amazing features with reduced risk.
Starting “left of left” is critical for secure user experience.
Security has been a consideration in the software user experience for a long time, yet clearly resulted in mixed success. Security misconfigurations accounted for 21% of cloud-based data breaches in the past year, with amateur-hour errors like storing passwords in plaintext resulting in some serious losses in productivity, revenue, and customer trust for affected companies.
That, and users themselves can be their own worst enemy when it comes to protecting their own data. Far too many people are still using “password” as their password, or using the same combination across multiple sensitive accounts.
I don’t know any developers who fist-pump the air when they’re told they have to work on a login screen, and it’s no wonder: it’s a delicate balance to design a security flow that is robust, functional, and that users will be able to navigate in a way that makes sense to them, with the least disruption.
Put in too many complex steps and restrictions, and users may switch off never to return (a disaster for a new app), make it too confusing, and you might end up giving the support team a collective migraine as they field queries from users trying to access their accounts. Make it too easy, and you’re kind of failing at the security part.
A successful secure user experience needs to weave tight security into a flow that makes sense, presented in a way that doesn’t detract from everything else that is compelling about the software. You can certainly meet the objective of coding a secure login function, putting in all manner of complex password requirements, CAPTCHA, mini-bosses, and four waves of zombies, but if it’s a total mess that is repellant to users, it’s missing the mark.
Lay the foundation for software excellence.
As a developer myself, I know that the vast majority of us take pride in our work, and want to do the right thing. Pesky curveballs like time constraints, sudden changes in the current objective, or urgent hotfixes can disrupt the flow and lead to mistakes, but the harsh truth is that many software engineers are not set up for success.
Starting “left of left” is a developer-first concept, and requires organizations to get serious about uplifting their engineering cohort. Security-aware developers are worth their weight in gold, and support in the form of training, provision of the right tools, and the opportunity to be mentored by more experienced developers will foster an environment where code is crafted with a security-first mindset, with the precision and attention to detail required to take software to the next level.
Ready to ignite the secure coding fire in yourself? Rise to the challenge.
Table of contents
Matias Madou, Ph.D. is a security expert, researcher, and CTO and co-founder of Secure Code Warrior. Matias obtained his Ph.D. in Application Security from Ghent University, focusing on static analysis solutions. He later joined Fortify in the US, where he realized that it was insufficient to solely detect code problems without aiding developers in writing secure code. This inspired him to develop products that assist developers, alleviate the burden of security, and exceed customers' expectations. When he is not at his desk as part of Team Awesome, he enjoys being on stage presenting at conferences including RSA Conference, BlackHat and DefCon.
Secure Code Warrior is here for your organization to help you secure code across the entire software development lifecycle and create a culture in which cybersecurity is top of mind. Whether you’re an AppSec Manager, Developer, CISO, or anyone involved in security, we can help your organization reduce risks associated with insecure code.
Book a demoDownloadResources to get you started
DigitalOcean Decreases Security Debt with Secure Code Warrior
DigitalOcean's use of Secure Code Warrior training has significantly reduced security debt, allowing teams to focus more on innovation and productivity. The improved security has strengthened their product quality and competitive edge. Looking ahead, the SCW Trust Score will help them further enhance security practices and continue driving innovation.
Resources to get you started
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.