Are your developers the first line of risk or defense? Rate your company against our Secure Coding Checklist
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.
Pieter Danhieux
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.
Related Articles We Recommend
Related Articles We Recommend
Dive into onto our latest secure coding insights on the blog.
Our extensive resource library aims to empower the human approach to secure coding upskilling.
Get the latest research on developer-driven security
Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.
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.
