Are your developers the first line of risk or defense? Rate your company against our Secure Coding Checklist
If we look at any organization, public or commercial, there are two things we can guarantee. Firstly, their products and services are increasingly digital, which means they involve software developers creating lines of code. Secondly, these digital businesses are under pressure from traditional and non-traditional competitors, operating in a more dynamic and global world.
Within this environment, CIOs have become the new innovators, and are in positions of power and influence. However, strong pressure to accelerate speed-to-market, enhance quality and increase flexibility has led to complex, distributed development teams, with a focus on rapid development of features and functions without cognisance of the vulnerabilities they could be creating.
More than ever before, a new way of working is required. You only need to look at the nuclear damage at Equifax following their recent breach, which was the result of insecure coding. CIOs and CISOs should think carefully about whether their development teams are the first line of risk, or are they the company's security champions, their company's true "first line of defense".
I have created this Secure Coding Checklist to help CIOs and CISOs consider whether you have set your development teams up to be secure coding champions who can help you innovate with faster, better and safer code.
1. Does your C-level executive recognise that traditional network security isn't enough?
Securing the network layer using traditional security measures is no longer sufficient and was rarely successful anyway, even against semi-professional hackers. Among many concurring reports, Verizon's 2017 Data Breach Investigations Report sites that 35 per cent of data breaches today are caused by web application vulnerabilities. Web application security is just as important as network security.
2. Are you thinking about security from the start?
Current application security tools focus on moving from right to left in the Software Development Life Cycle (SDLC). This approach supports detection and reaction, meaning security teams detect the vulnerabilities in the written code and react to fix them. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them when writing code in the IDE. Not to mention the time delays incurred in remedying the issue. Secure code champions start at the extreme left of the SDLC, with a focus on continually training their developers in secure coding, so they can be the first line of defence in their organization, preventing vulnerabilities in the first place.
3. Do you actually build security skills instead of only feeding knowledge?
Most training solutions (online and in-classroom) focus on building knowledge rather than building skills. For developers to write secure code, they need regular access to hands-on learning that actively engages them to learn and build their secure coding skills. They need to learn about recent identified vulnerabilities, in real code, and in their own languages/frameworks. This learning experience should help them understand how to locate, identify and fix known vulnerabilities in code.
4. Do you measure your secure coding skills with real-time metrics?
It is important to create evidence that proves to the developer and her organization that a developer's secure coding skills are improving. You can't improve what you cannot measure. Your assessments should help identify the progress of your development teams in real time as well as benchmarking their secure coding strengths and weaknesses.
5. Are you sure your outsourced suppliers apply secure coding techniques?
Many organization decide to contract out development work to large onshore or offshore development houses. In the best case, the only form of assurance an organization asks on security, is a statement in the contract requiring the deliverable to be "secure". Few actually verify the skills of these development houses upfront and end-up with software that is not following good secure coding practices. The worst case scenario is that they do not know about them and go live with the application. The most common scenario is they get picked up by dedicated specialists (for which you pay) and you are confronted with either delays in go-live, and contractual discussions on who needs to pay for fixing these security weaknesses. Be smart upfront, and assess the application security skills of the developers who are going to buid your next application.
6. Are your developers aware of the most common security weaknesses?
85.5% of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities " the OWASP Top 10. Your application security training needs to cover these at minimum and many more vulnerability types. The challenges your developers complete with need to be continuously revised and updated with new challenges for either new coding frameworks or new vulnerability types.
7. Do you have in-house security champions?
Every developer-heavy organization should invest in someone who is going to champion security within your development teams. Their purpose is to be a support point of contact for anyone with questions around security but also to advocate secure coding and secure architecture practices within a team
8. Have you invested in tools for your developers to make secure coding easier?
In an environment with many changes to applications or where agile development is practised, automating parts of security is essential to keep up with the pace and volume. There are tools available at each stage of the development life-cycle that will serve as advisors, quality gates or detection tools. You should have IDE PlugIns that focus on certain types of security bugs and act like spell checkers while the developer is writing his or her code. There are also tools which integrate with the build process that detect certain types of weaknesses when code is being submitted to a code repository. There are also tools which run automated tests over the code, simulating hacking techniques once the software is in production. All have their own set of benefits and challenges, and none can provide a 100% guarantee there are no security issues. The golden rule, the earlier you can capture the weakness, the faster and cheaper it is to remediate the weakness with the least impact on your business.
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
How did your organization go against this checklist?
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction.
Chief Executive Officer, Chairman, and Co-Founder
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 demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
If we look at any organization, public or commercial, there are two things we can guarantee. Firstly, their products and services are increasingly digital, which means they involve software developers creating lines of code. Secondly, these digital businesses are under pressure from traditional and non-traditional competitors, operating in a more dynamic and global world.
Within this environment, CIOs have become the new innovators, and are in positions of power and influence. However, strong pressure to accelerate speed-to-market, enhance quality and increase flexibility has led to complex, distributed development teams, with a focus on rapid development of features and functions without cognisance of the vulnerabilities they could be creating.
More than ever before, a new way of working is required. You only need to look at the nuclear damage at Equifax following their recent breach, which was the result of insecure coding. CIOs and CISOs should think carefully about whether their development teams are the first line of risk, or are they the company's security champions, their company's true "first line of defense".
I have created this Secure Coding Checklist to help CIOs and CISOs consider whether you have set your development teams up to be secure coding champions who can help you innovate with faster, better and safer code.
1. Does your C-level executive recognise that traditional network security isn't enough?
Securing the network layer using traditional security measures is no longer sufficient and was rarely successful anyway, even against semi-professional hackers. Among many concurring reports, Verizon's 2017 Data Breach Investigations Report sites that 35 per cent of data breaches today are caused by web application vulnerabilities. Web application security is just as important as network security.
2. Are you thinking about security from the start?
Current application security tools focus on moving from right to left in the Software Development Life Cycle (SDLC). This approach supports detection and reaction, meaning security teams detect the vulnerabilities in the written code and react to fix them. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them when writing code in the IDE. Not to mention the time delays incurred in remedying the issue. Secure code champions start at the extreme left of the SDLC, with a focus on continually training their developers in secure coding, so they can be the first line of defence in their organization, preventing vulnerabilities in the first place.
3. Do you actually build security skills instead of only feeding knowledge?
Most training solutions (online and in-classroom) focus on building knowledge rather than building skills. For developers to write secure code, they need regular access to hands-on learning that actively engages them to learn and build their secure coding skills. They need to learn about recent identified vulnerabilities, in real code, and in their own languages/frameworks. This learning experience should help them understand how to locate, identify and fix known vulnerabilities in code.
4. Do you measure your secure coding skills with real-time metrics?
It is important to create evidence that proves to the developer and her organization that a developer's secure coding skills are improving. You can't improve what you cannot measure. Your assessments should help identify the progress of your development teams in real time as well as benchmarking their secure coding strengths and weaknesses.
5. Are you sure your outsourced suppliers apply secure coding techniques?
Many organization decide to contract out development work to large onshore or offshore development houses. In the best case, the only form of assurance an organization asks on security, is a statement in the contract requiring the deliverable to be "secure". Few actually verify the skills of these development houses upfront and end-up with software that is not following good secure coding practices. The worst case scenario is that they do not know about them and go live with the application. The most common scenario is they get picked up by dedicated specialists (for which you pay) and you are confronted with either delays in go-live, and contractual discussions on who needs to pay for fixing these security weaknesses. Be smart upfront, and assess the application security skills of the developers who are going to buid your next application.
6. Are your developers aware of the most common security weaknesses?
85.5% of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities " the OWASP Top 10. Your application security training needs to cover these at minimum and many more vulnerability types. The challenges your developers complete with need to be continuously revised and updated with new challenges for either new coding frameworks or new vulnerability types.
7. Do you have in-house security champions?
Every developer-heavy organization should invest in someone who is going to champion security within your development teams. Their purpose is to be a support point of contact for anyone with questions around security but also to advocate secure coding and secure architecture practices within a team
8. Have you invested in tools for your developers to make secure coding easier?
In an environment with many changes to applications or where agile development is practised, automating parts of security is essential to keep up with the pace and volume. There are tools available at each stage of the development life-cycle that will serve as advisors, quality gates or detection tools. You should have IDE PlugIns that focus on certain types of security bugs and act like spell checkers while the developer is writing his or her code. There are also tools which integrate with the build process that detect certain types of weaknesses when code is being submitted to a code repository. There are also tools which run automated tests over the code, simulating hacking techniques once the software is in production. All have their own set of benefits and challenges, and none can provide a 100% guarantee there are no security issues. The golden rule, the earlier you can capture the weakness, the faster and cheaper it is to remediate the weakness with the least impact on your business.
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
How did your organization go against this checklist?
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
If we look at any organization, public or commercial, there are two things we can guarantee. Firstly, their products and services are increasingly digital, which means they involve software developers creating lines of code. Secondly, these digital businesses are under pressure from traditional and non-traditional competitors, operating in a more dynamic and global world.
Within this environment, CIOs have become the new innovators, and are in positions of power and influence. However, strong pressure to accelerate speed-to-market, enhance quality and increase flexibility has led to complex, distributed development teams, with a focus on rapid development of features and functions without cognisance of the vulnerabilities they could be creating.
More than ever before, a new way of working is required. You only need to look at the nuclear damage at Equifax following their recent breach, which was the result of insecure coding. CIOs and CISOs should think carefully about whether their development teams are the first line of risk, or are they the company's security champions, their company's true "first line of defense".
I have created this Secure Coding Checklist to help CIOs and CISOs consider whether you have set your development teams up to be secure coding champions who can help you innovate with faster, better and safer code.
1. Does your C-level executive recognise that traditional network security isn't enough?
Securing the network layer using traditional security measures is no longer sufficient and was rarely successful anyway, even against semi-professional hackers. Among many concurring reports, Verizon's 2017 Data Breach Investigations Report sites that 35 per cent of data breaches today are caused by web application vulnerabilities. Web application security is just as important as network security.
2. Are you thinking about security from the start?
Current application security tools focus on moving from right to left in the Software Development Life Cycle (SDLC). This approach supports detection and reaction, meaning security teams detect the vulnerabilities in the written code and react to fix them. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them when writing code in the IDE. Not to mention the time delays incurred in remedying the issue. Secure code champions start at the extreme left of the SDLC, with a focus on continually training their developers in secure coding, so they can be the first line of defence in their organization, preventing vulnerabilities in the first place.
3. Do you actually build security skills instead of only feeding knowledge?
Most training solutions (online and in-classroom) focus on building knowledge rather than building skills. For developers to write secure code, they need regular access to hands-on learning that actively engages them to learn and build their secure coding skills. They need to learn about recent identified vulnerabilities, in real code, and in their own languages/frameworks. This learning experience should help them understand how to locate, identify and fix known vulnerabilities in code.
4. Do you measure your secure coding skills with real-time metrics?
It is important to create evidence that proves to the developer and her organization that a developer's secure coding skills are improving. You can't improve what you cannot measure. Your assessments should help identify the progress of your development teams in real time as well as benchmarking their secure coding strengths and weaknesses.
5. Are you sure your outsourced suppliers apply secure coding techniques?
Many organization decide to contract out development work to large onshore or offshore development houses. In the best case, the only form of assurance an organization asks on security, is a statement in the contract requiring the deliverable to be "secure". Few actually verify the skills of these development houses upfront and end-up with software that is not following good secure coding practices. The worst case scenario is that they do not know about them and go live with the application. The most common scenario is they get picked up by dedicated specialists (for which you pay) and you are confronted with either delays in go-live, and contractual discussions on who needs to pay for fixing these security weaknesses. Be smart upfront, and assess the application security skills of the developers who are going to buid your next application.
6. Are your developers aware of the most common security weaknesses?
85.5% of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities " the OWASP Top 10. Your application security training needs to cover these at minimum and many more vulnerability types. The challenges your developers complete with need to be continuously revised and updated with new challenges for either new coding frameworks or new vulnerability types.
7. Do you have in-house security champions?
Every developer-heavy organization should invest in someone who is going to champion security within your development teams. Their purpose is to be a support point of contact for anyone with questions around security but also to advocate secure coding and secure architecture practices within a team
8. Have you invested in tools for your developers to make secure coding easier?
In an environment with many changes to applications or where agile development is practised, automating parts of security is essential to keep up with the pace and volume. There are tools available at each stage of the development life-cycle that will serve as advisors, quality gates or detection tools. You should have IDE PlugIns that focus on certain types of security bugs and act like spell checkers while the developer is writing his or her code. There are also tools which integrate with the build process that detect certain types of weaknesses when code is being submitted to a code repository. There are also tools which run automated tests over the code, simulating hacking techniques once the software is in production. All have their own set of benefits and challenges, and none can provide a 100% guarantee there are no security issues. The golden rule, the earlier you can capture the weakness, the faster and cheaper it is to remediate the weakness with the least impact on your business.
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
How did your organization go against this checklist?
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
Click on the link below and download the PDF of this resource.
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.
View reportBook a demoChief Executive Officer, Chairman, and Co-Founder
Pieter Danhieux is a globally recognized security expert, with over 12 years experience as a security consultant and 8 years as a Principal Instructor for SANS teaching offensive techniques on how to target and assess organizations, systems and individuals for security weaknesses. In 2016, he was recognized as one of the Coolest Tech people in Australia (Business Insider), awarded Cyber Security Professional of the Year (AISA - Australian Information Security Association) and holds GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA certifications.
If we look at any organization, public or commercial, there are two things we can guarantee. Firstly, their products and services are increasingly digital, which means they involve software developers creating lines of code. Secondly, these digital businesses are under pressure from traditional and non-traditional competitors, operating in a more dynamic and global world.
Within this environment, CIOs have become the new innovators, and are in positions of power and influence. However, strong pressure to accelerate speed-to-market, enhance quality and increase flexibility has led to complex, distributed development teams, with a focus on rapid development of features and functions without cognisance of the vulnerabilities they could be creating.
More than ever before, a new way of working is required. You only need to look at the nuclear damage at Equifax following their recent breach, which was the result of insecure coding. CIOs and CISOs should think carefully about whether their development teams are the first line of risk, or are they the company's security champions, their company's true "first line of defense".
I have created this Secure Coding Checklist to help CIOs and CISOs consider whether you have set your development teams up to be secure coding champions who can help you innovate with faster, better and safer code.
1. Does your C-level executive recognise that traditional network security isn't enough?
Securing the network layer using traditional security measures is no longer sufficient and was rarely successful anyway, even against semi-professional hackers. Among many concurring reports, Verizon's 2017 Data Breach Investigations Report sites that 35 per cent of data breaches today are caused by web application vulnerabilities. Web application security is just as important as network security.
2. Are you thinking about security from the start?
Current application security tools focus on moving from right to left in the Software Development Life Cycle (SDLC). This approach supports detection and reaction, meaning security teams detect the vulnerabilities in the written code and react to fix them. According to the National Institute of Standards and Technology (NIST), it is 30 times more expensive to detect and fix vulnerabilities in committed code than it is to prevent them when writing code in the IDE. Not to mention the time delays incurred in remedying the issue. Secure code champions start at the extreme left of the SDLC, with a focus on continually training their developers in secure coding, so they can be the first line of defence in their organization, preventing vulnerabilities in the first place.
3. Do you actually build security skills instead of only feeding knowledge?
Most training solutions (online and in-classroom) focus on building knowledge rather than building skills. For developers to write secure code, they need regular access to hands-on learning that actively engages them to learn and build their secure coding skills. They need to learn about recent identified vulnerabilities, in real code, and in their own languages/frameworks. This learning experience should help them understand how to locate, identify and fix known vulnerabilities in code.
4. Do you measure your secure coding skills with real-time metrics?
It is important to create evidence that proves to the developer and her organization that a developer's secure coding skills are improving. You can't improve what you cannot measure. Your assessments should help identify the progress of your development teams in real time as well as benchmarking their secure coding strengths and weaknesses.
5. Are you sure your outsourced suppliers apply secure coding techniques?
Many organization decide to contract out development work to large onshore or offshore development houses. In the best case, the only form of assurance an organization asks on security, is a statement in the contract requiring the deliverable to be "secure". Few actually verify the skills of these development houses upfront and end-up with software that is not following good secure coding practices. The worst case scenario is that they do not know about them and go live with the application. The most common scenario is they get picked up by dedicated specialists (for which you pay) and you are confronted with either delays in go-live, and contractual discussions on who needs to pay for fixing these security weaknesses. Be smart upfront, and assess the application security skills of the developers who are going to buid your next application.
6. Are your developers aware of the most common security weaknesses?
85.5% of exploited web application vulnerabilities are attributed to just 10 known vulnerabilities " the OWASP Top 10. Your application security training needs to cover these at minimum and many more vulnerability types. The challenges your developers complete with need to be continuously revised and updated with new challenges for either new coding frameworks or new vulnerability types.
7. Do you have in-house security champions?
Every developer-heavy organization should invest in someone who is going to champion security within your development teams. Their purpose is to be a support point of contact for anyone with questions around security but also to advocate secure coding and secure architecture practices within a team
8. Have you invested in tools for your developers to make secure coding easier?
In an environment with many changes to applications or where agile development is practised, automating parts of security is essential to keep up with the pace and volume. There are tools available at each stage of the development life-cycle that will serve as advisors, quality gates or detection tools. You should have IDE PlugIns that focus on certain types of security bugs and act like spell checkers while the developer is writing his or her code. There are also tools which integrate with the build process that detect certain types of weaknesses when code is being submitted to a code repository. There are also tools which run automated tests over the code, simulating hacking techniques once the software is in production. All have their own set of benefits and challenges, and none can provide a 100% guarantee there are no security issues. The golden rule, the earlier you can capture the weakness, the faster and cheaper it is to remediate the weakness with the least impact on your business.
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
How did your organization go against this checklist?
As CIOs aggressively build their enterprise agile capabilities, secure coding skills will be a weapon of innovation and not having them will be an instrument of destruction. Think twice before you skip this critical capability.
Table of contents
Chief Executive Officer, Chairman, and Co-Founder
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
Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise
The Secure-by-Design movement is the future of secure software development. Learn about the key elements companies need to keep in mind when they think about a Secure-by-Design initiative.
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
Trust Score Reveals the Value of Secure-by-Design Upskilling Initiatives
Our research has shown that secure code training works. Trust Score, using an algorithm drawing on more than 20 million learning data points from work by more than 250,000 learners at over 600 organizations, reveals its effectiveness in driving down vulnerabilities and how to make the initiative even more effective.
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.