Turning boring PCI-DSS compliance into a meaningful exercise for everybody: Part 1 - AppSec
This is part 1 of a two-part series on successful PCI-DSS compliance within an organization. In this chapter, we detail how AppSec specialists can work closely with development managers to empower developers, strengthen the SSDLC and get specific outcomes from general legislation.
The word "compliance" isn't very exciting. It's formal, dry, directive... even a little restrictive in its tone. If it had a color, it would be beige. And, well, it seems at odds with any sort of creative environment or innovation.
As a developer myself, my experience of "being compliant'usually meant (vertically) reading through some guidelines or watching a presentation, before going back to coding features and focusing on creating software that customers will use and love. Everyone retains what they can in the moment (and tries to do the right thing at all times), but compliance guidelines -- especially those surrounding security best practice -- are not typically written with developers as the target audience, and any required actions can be unclear. In that scenario, it's all too easy to just stay on-task with current objectives.
The thing is, secure software development is no longer a "nice to have" in any company; it is (or should be) front-of-mind in every organization... and if it's holding vast amounts of sensitive customer information, then that company is ripe for the picking when it comes to cyberattacks. Developers are the first to get hands-on with code, and as such, should be just as involved as the rest of the team in any security compliance measures.
But, wait... hear me out. This doesn't mean everyone has to become a slave to rigid, creativity-free development and software outcomes. It means the business has the opportunity and power to create a higher standard of code, together. Ever so slowly, the world is catching up to the fact that, to date, developers haven't exactly had the right tools at their disposal to make security a priority (and siloed security specialists cannot shoulder the responsibility alone). However, as the industry moves towards a DevSecOps future with security as a shared responsibility, they can help stem the flow of recurring vulnerabilities when set up for success.
The PCI-DSS guidelines cover online security compliance for card payment gateways - a service most of us use on a regular basis. These guidelines are globally applicable, and they have actually outlined in detail what developers must do to maintain standards in-line with their mandates, alongside several compliance documents across aspects of eCommerce business.
Data breaches are scary, reputation-destroying risks that businesses can ill-afford, and with Cyber Security Ventures tipping zero-day breaches to reach one per day in 2021, this is something that everyone in the software delivery process can help fight.
Let's break down the PCI-DSS recommendations, and how they can work across the team:
Hey, AppSec and Compliance teams: All developer training is not created equal
Developers in large (or even small) organizations rarely have a whole lot of input into the training they receive on-the-job. In order to retain star employees, some companies do offer comprehensive programs, but these are still less common than they should be. A need for security training presents a great opportunity to not only kick-off organizational compliance without boring everyone to tears, but also start to warm up any frosty relationships with the development team.
In terms of PCI compliance, you can see that their guidelines are specific as to the outcomes they would expect from any software running payment gateways; among other objectives, they want applications hardened (vital for thwarting malicious code injection or tampering), least-privilege controls and full-scale awareness of common vulnerabilities... at a minimum. All personnel working with cardholder data must be adequately trained, and for developers, that training can make or break their success in writing secure code from the start of their process.
The official Best Practices for Maintaining PCI-DSS Compliance document details some direct concepts around security awareness, developer needs, and appropriate training, like:
Copyright © 2006 - 2020 PCI Security Standards Council, LLC. All rights reserved.
This gives insight into the specific, in-depth training required to arm developers with the necessary skills, but still doesn't point to any particular types of educational solutions as more effective than another. The PCI-DSS Guide for Developers gets a little more direct, identifying the OWASP Top 10 as one benchmark for learning to find and fix the most common vulnerabilities, as well as some certification programs.
But... here's the rub. As you would no doubt know from various workplace training and compliance initiatives, they can vary wildly in quality and future success. And when it comes to developers, so many secure coding training programs don't seem to cater to our needs, ways of working or even our day-to-day jobs in any meaningful capacity. In this scenario, not all training is created equal, and not all training is going to result in software that is more secure. This is, of course, the exact opposite of your desired outcome, and won't make the stress of your own job reduce in any significant measure. If you want to reduce the burden and stop common vulnerabilities from causing potential disasters, you'll need to build a bridge.
Bridging the security skills gap with engineering managers on your side
Working directly with engineering managers to find a solution that is fit for purpose, while still being embraced by the people who actually have to do it, is a fast-track to positive security outcomes. They will have more immediate insights into their own team, and can speak to any blockers that have previously made compliance training difficult (other than it not being a great experience, most of the time).
Classroom-based training, video-on-demand and any once-off, tick-the-box exercises make staying current very difficult; these are static solutions that cannot keep pace with the ever-changing landscape that is the cybersecurity industry. Ultimately, the engineering manager will want to see value for the time commitment, and it's important to work with them and provide viable options that work to meet everyone's shared goal: code that is more secure and compliant.
So, what does good training look like? There is very little point to learning how to code securely via big, once-off hits of information. A bite-sized, gradual learning process makes it far easier to remember and apply in-context, and it absolutely must be in the languages and frameworks used every day. Personally, I want to be challenged, and I want to see a purpose for my efforts - we're all busy enough as it is, right?
To comply with the PCI-DSS best practices outlined above, depending on the solution chosen, managers might find themselves a having to stitch together a patchwork of different courses to cover all languages and frameworks used across the business, and that's when things get very messy, not to mention difficult for AppSec and compliance teams to assess as making an impact on security and vulnerability reduction in software. Work together to find the right fit, instead of rushing into the wrong option chasing a fast result. Otherwise, you might end up with a Frankenstein training solution... and that looks very scary.
Thanks for checking out part one of this PCI-DSS mini-series. In the final chapter, we will discuss how CISOs and CTOs can help this culture transformation, enable teams, and how the security front lines " your developer cohort " can use PCI-DSS awareness and compliance to their advantage.
This is part 1 of a two-part series on successful PCI-DSS compliance within an organization. In this chapter, we detail how AppSec specialists can work closely with development managers to empower developers, strengthen the SSDLC and get specific outcomes from general legislation.
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.
This is part 1 of a two-part series on successful PCI-DSS compliance within an organization. In this chapter, we detail how AppSec specialists can work closely with development managers to empower developers, strengthen the SSDLC and get specific outcomes from general legislation.
The word "compliance" isn't very exciting. It's formal, dry, directive... even a little restrictive in its tone. If it had a color, it would be beige. And, well, it seems at odds with any sort of creative environment or innovation.
As a developer myself, my experience of "being compliant'usually meant (vertically) reading through some guidelines or watching a presentation, before going back to coding features and focusing on creating software that customers will use and love. Everyone retains what they can in the moment (and tries to do the right thing at all times), but compliance guidelines -- especially those surrounding security best practice -- are not typically written with developers as the target audience, and any required actions can be unclear. In that scenario, it's all too easy to just stay on-task with current objectives.
The thing is, secure software development is no longer a "nice to have" in any company; it is (or should be) front-of-mind in every organization... and if it's holding vast amounts of sensitive customer information, then that company is ripe for the picking when it comes to cyberattacks. Developers are the first to get hands-on with code, and as such, should be just as involved as the rest of the team in any security compliance measures.
But, wait... hear me out. This doesn't mean everyone has to become a slave to rigid, creativity-free development and software outcomes. It means the business has the opportunity and power to create a higher standard of code, together. Ever so slowly, the world is catching up to the fact that, to date, developers haven't exactly had the right tools at their disposal to make security a priority (and siloed security specialists cannot shoulder the responsibility alone). However, as the industry moves towards a DevSecOps future with security as a shared responsibility, they can help stem the flow of recurring vulnerabilities when set up for success.
The PCI-DSS guidelines cover online security compliance for card payment gateways - a service most of us use on a regular basis. These guidelines are globally applicable, and they have actually outlined in detail what developers must do to maintain standards in-line with their mandates, alongside several compliance documents across aspects of eCommerce business.
Data breaches are scary, reputation-destroying risks that businesses can ill-afford, and with Cyber Security Ventures tipping zero-day breaches to reach one per day in 2021, this is something that everyone in the software delivery process can help fight.
Let's break down the PCI-DSS recommendations, and how they can work across the team:
Hey, AppSec and Compliance teams: All developer training is not created equal
Developers in large (or even small) organizations rarely have a whole lot of input into the training they receive on-the-job. In order to retain star employees, some companies do offer comprehensive programs, but these are still less common than they should be. A need for security training presents a great opportunity to not only kick-off organizational compliance without boring everyone to tears, but also start to warm up any frosty relationships with the development team.
In terms of PCI compliance, you can see that their guidelines are specific as to the outcomes they would expect from any software running payment gateways; among other objectives, they want applications hardened (vital for thwarting malicious code injection or tampering), least-privilege controls and full-scale awareness of common vulnerabilities... at a minimum. All personnel working with cardholder data must be adequately trained, and for developers, that training can make or break their success in writing secure code from the start of their process.
The official Best Practices for Maintaining PCI-DSS Compliance document details some direct concepts around security awareness, developer needs, and appropriate training, like:
Copyright © 2006 - 2020 PCI Security Standards Council, LLC. All rights reserved.
This gives insight into the specific, in-depth training required to arm developers with the necessary skills, but still doesn't point to any particular types of educational solutions as more effective than another. The PCI-DSS Guide for Developers gets a little more direct, identifying the OWASP Top 10 as one benchmark for learning to find and fix the most common vulnerabilities, as well as some certification programs.
But... here's the rub. As you would no doubt know from various workplace training and compliance initiatives, they can vary wildly in quality and future success. And when it comes to developers, so many secure coding training programs don't seem to cater to our needs, ways of working or even our day-to-day jobs in any meaningful capacity. In this scenario, not all training is created equal, and not all training is going to result in software that is more secure. This is, of course, the exact opposite of your desired outcome, and won't make the stress of your own job reduce in any significant measure. If you want to reduce the burden and stop common vulnerabilities from causing potential disasters, you'll need to build a bridge.
Bridging the security skills gap with engineering managers on your side
Working directly with engineering managers to find a solution that is fit for purpose, while still being embraced by the people who actually have to do it, is a fast-track to positive security outcomes. They will have more immediate insights into their own team, and can speak to any blockers that have previously made compliance training difficult (other than it not being a great experience, most of the time).
Classroom-based training, video-on-demand and any once-off, tick-the-box exercises make staying current very difficult; these are static solutions that cannot keep pace with the ever-changing landscape that is the cybersecurity industry. Ultimately, the engineering manager will want to see value for the time commitment, and it's important to work with them and provide viable options that work to meet everyone's shared goal: code that is more secure and compliant.
So, what does good training look like? There is very little point to learning how to code securely via big, once-off hits of information. A bite-sized, gradual learning process makes it far easier to remember and apply in-context, and it absolutely must be in the languages and frameworks used every day. Personally, I want to be challenged, and I want to see a purpose for my efforts - we're all busy enough as it is, right?
To comply with the PCI-DSS best practices outlined above, depending on the solution chosen, managers might find themselves a having to stitch together a patchwork of different courses to cover all languages and frameworks used across the business, and that's when things get very messy, not to mention difficult for AppSec and compliance teams to assess as making an impact on security and vulnerability reduction in software. Work together to find the right fit, instead of rushing into the wrong option chasing a fast result. Otherwise, you might end up with a Frankenstein training solution... and that looks very scary.
Thanks for checking out part one of this PCI-DSS mini-series. In the final chapter, we will discuss how CISOs and CTOs can help this culture transformation, enable teams, and how the security front lines " your developer cohort " can use PCI-DSS awareness and compliance to their advantage.
This is part 1 of a two-part series on successful PCI-DSS compliance within an organization. In this chapter, we detail how AppSec specialists can work closely with development managers to empower developers, strengthen the SSDLC and get specific outcomes from general legislation.
The word "compliance" isn't very exciting. It's formal, dry, directive... even a little restrictive in its tone. If it had a color, it would be beige. And, well, it seems at odds with any sort of creative environment or innovation.
As a developer myself, my experience of "being compliant'usually meant (vertically) reading through some guidelines or watching a presentation, before going back to coding features and focusing on creating software that customers will use and love. Everyone retains what they can in the moment (and tries to do the right thing at all times), but compliance guidelines -- especially those surrounding security best practice -- are not typically written with developers as the target audience, and any required actions can be unclear. In that scenario, it's all too easy to just stay on-task with current objectives.
The thing is, secure software development is no longer a "nice to have" in any company; it is (or should be) front-of-mind in every organization... and if it's holding vast amounts of sensitive customer information, then that company is ripe for the picking when it comes to cyberattacks. Developers are the first to get hands-on with code, and as such, should be just as involved as the rest of the team in any security compliance measures.
But, wait... hear me out. This doesn't mean everyone has to become a slave to rigid, creativity-free development and software outcomes. It means the business has the opportunity and power to create a higher standard of code, together. Ever so slowly, the world is catching up to the fact that, to date, developers haven't exactly had the right tools at their disposal to make security a priority (and siloed security specialists cannot shoulder the responsibility alone). However, as the industry moves towards a DevSecOps future with security as a shared responsibility, they can help stem the flow of recurring vulnerabilities when set up for success.
The PCI-DSS guidelines cover online security compliance for card payment gateways - a service most of us use on a regular basis. These guidelines are globally applicable, and they have actually outlined in detail what developers must do to maintain standards in-line with their mandates, alongside several compliance documents across aspects of eCommerce business.
Data breaches are scary, reputation-destroying risks that businesses can ill-afford, and with Cyber Security Ventures tipping zero-day breaches to reach one per day in 2021, this is something that everyone in the software delivery process can help fight.
Let's break down the PCI-DSS recommendations, and how they can work across the team:
Hey, AppSec and Compliance teams: All developer training is not created equal
Developers in large (or even small) organizations rarely have a whole lot of input into the training they receive on-the-job. In order to retain star employees, some companies do offer comprehensive programs, but these are still less common than they should be. A need for security training presents a great opportunity to not only kick-off organizational compliance without boring everyone to tears, but also start to warm up any frosty relationships with the development team.
In terms of PCI compliance, you can see that their guidelines are specific as to the outcomes they would expect from any software running payment gateways; among other objectives, they want applications hardened (vital for thwarting malicious code injection or tampering), least-privilege controls and full-scale awareness of common vulnerabilities... at a minimum. All personnel working with cardholder data must be adequately trained, and for developers, that training can make or break their success in writing secure code from the start of their process.
The official Best Practices for Maintaining PCI-DSS Compliance document details some direct concepts around security awareness, developer needs, and appropriate training, like:
Copyright © 2006 - 2020 PCI Security Standards Council, LLC. All rights reserved.
This gives insight into the specific, in-depth training required to arm developers with the necessary skills, but still doesn't point to any particular types of educational solutions as more effective than another. The PCI-DSS Guide for Developers gets a little more direct, identifying the OWASP Top 10 as one benchmark for learning to find and fix the most common vulnerabilities, as well as some certification programs.
But... here's the rub. As you would no doubt know from various workplace training and compliance initiatives, they can vary wildly in quality and future success. And when it comes to developers, so many secure coding training programs don't seem to cater to our needs, ways of working or even our day-to-day jobs in any meaningful capacity. In this scenario, not all training is created equal, and not all training is going to result in software that is more secure. This is, of course, the exact opposite of your desired outcome, and won't make the stress of your own job reduce in any significant measure. If you want to reduce the burden and stop common vulnerabilities from causing potential disasters, you'll need to build a bridge.
Bridging the security skills gap with engineering managers on your side
Working directly with engineering managers to find a solution that is fit for purpose, while still being embraced by the people who actually have to do it, is a fast-track to positive security outcomes. They will have more immediate insights into their own team, and can speak to any blockers that have previously made compliance training difficult (other than it not being a great experience, most of the time).
Classroom-based training, video-on-demand and any once-off, tick-the-box exercises make staying current very difficult; these are static solutions that cannot keep pace with the ever-changing landscape that is the cybersecurity industry. Ultimately, the engineering manager will want to see value for the time commitment, and it's important to work with them and provide viable options that work to meet everyone's shared goal: code that is more secure and compliant.
So, what does good training look like? There is very little point to learning how to code securely via big, once-off hits of information. A bite-sized, gradual learning process makes it far easier to remember and apply in-context, and it absolutely must be in the languages and frameworks used every day. Personally, I want to be challenged, and I want to see a purpose for my efforts - we're all busy enough as it is, right?
To comply with the PCI-DSS best practices outlined above, depending on the solution chosen, managers might find themselves a having to stitch together a patchwork of different courses to cover all languages and frameworks used across the business, and that's when things get very messy, not to mention difficult for AppSec and compliance teams to assess as making an impact on security and vulnerability reduction in software. Work together to find the right fit, instead of rushing into the wrong option chasing a fast result. Otherwise, you might end up with a Frankenstein training solution... and that looks very scary.
Thanks for checking out part one of this PCI-DSS mini-series. In the final chapter, we will discuss how CISOs and CTOs can help this culture transformation, enable teams, and how the security front lines " your developer cohort " can use PCI-DSS awareness and compliance to their advantage.
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 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.
This is part 1 of a two-part series on successful PCI-DSS compliance within an organization. In this chapter, we detail how AppSec specialists can work closely with development managers to empower developers, strengthen the SSDLC and get specific outcomes from general legislation.
The word "compliance" isn't very exciting. It's formal, dry, directive... even a little restrictive in its tone. If it had a color, it would be beige. And, well, it seems at odds with any sort of creative environment or innovation.
As a developer myself, my experience of "being compliant'usually meant (vertically) reading through some guidelines or watching a presentation, before going back to coding features and focusing on creating software that customers will use and love. Everyone retains what they can in the moment (and tries to do the right thing at all times), but compliance guidelines -- especially those surrounding security best practice -- are not typically written with developers as the target audience, and any required actions can be unclear. In that scenario, it's all too easy to just stay on-task with current objectives.
The thing is, secure software development is no longer a "nice to have" in any company; it is (or should be) front-of-mind in every organization... and if it's holding vast amounts of sensitive customer information, then that company is ripe for the picking when it comes to cyberattacks. Developers are the first to get hands-on with code, and as such, should be just as involved as the rest of the team in any security compliance measures.
But, wait... hear me out. This doesn't mean everyone has to become a slave to rigid, creativity-free development and software outcomes. It means the business has the opportunity and power to create a higher standard of code, together. Ever so slowly, the world is catching up to the fact that, to date, developers haven't exactly had the right tools at their disposal to make security a priority (and siloed security specialists cannot shoulder the responsibility alone). However, as the industry moves towards a DevSecOps future with security as a shared responsibility, they can help stem the flow of recurring vulnerabilities when set up for success.
The PCI-DSS guidelines cover online security compliance for card payment gateways - a service most of us use on a regular basis. These guidelines are globally applicable, and they have actually outlined in detail what developers must do to maintain standards in-line with their mandates, alongside several compliance documents across aspects of eCommerce business.
Data breaches are scary, reputation-destroying risks that businesses can ill-afford, and with Cyber Security Ventures tipping zero-day breaches to reach one per day in 2021, this is something that everyone in the software delivery process can help fight.
Let's break down the PCI-DSS recommendations, and how they can work across the team:
Hey, AppSec and Compliance teams: All developer training is not created equal
Developers in large (or even small) organizations rarely have a whole lot of input into the training they receive on-the-job. In order to retain star employees, some companies do offer comprehensive programs, but these are still less common than they should be. A need for security training presents a great opportunity to not only kick-off organizational compliance without boring everyone to tears, but also start to warm up any frosty relationships with the development team.
In terms of PCI compliance, you can see that their guidelines are specific as to the outcomes they would expect from any software running payment gateways; among other objectives, they want applications hardened (vital for thwarting malicious code injection or tampering), least-privilege controls and full-scale awareness of common vulnerabilities... at a minimum. All personnel working with cardholder data must be adequately trained, and for developers, that training can make or break their success in writing secure code from the start of their process.
The official Best Practices for Maintaining PCI-DSS Compliance document details some direct concepts around security awareness, developer needs, and appropriate training, like:
Copyright © 2006 - 2020 PCI Security Standards Council, LLC. All rights reserved.
This gives insight into the specific, in-depth training required to arm developers with the necessary skills, but still doesn't point to any particular types of educational solutions as more effective than another. The PCI-DSS Guide for Developers gets a little more direct, identifying the OWASP Top 10 as one benchmark for learning to find and fix the most common vulnerabilities, as well as some certification programs.
But... here's the rub. As you would no doubt know from various workplace training and compliance initiatives, they can vary wildly in quality and future success. And when it comes to developers, so many secure coding training programs don't seem to cater to our needs, ways of working or even our day-to-day jobs in any meaningful capacity. In this scenario, not all training is created equal, and not all training is going to result in software that is more secure. This is, of course, the exact opposite of your desired outcome, and won't make the stress of your own job reduce in any significant measure. If you want to reduce the burden and stop common vulnerabilities from causing potential disasters, you'll need to build a bridge.
Bridging the security skills gap with engineering managers on your side
Working directly with engineering managers to find a solution that is fit for purpose, while still being embraced by the people who actually have to do it, is a fast-track to positive security outcomes. They will have more immediate insights into their own team, and can speak to any blockers that have previously made compliance training difficult (other than it not being a great experience, most of the time).
Classroom-based training, video-on-demand and any once-off, tick-the-box exercises make staying current very difficult; these are static solutions that cannot keep pace with the ever-changing landscape that is the cybersecurity industry. Ultimately, the engineering manager will want to see value for the time commitment, and it's important to work with them and provide viable options that work to meet everyone's shared goal: code that is more secure and compliant.
So, what does good training look like? There is very little point to learning how to code securely via big, once-off hits of information. A bite-sized, gradual learning process makes it far easier to remember and apply in-context, and it absolutely must be in the languages and frameworks used every day. Personally, I want to be challenged, and I want to see a purpose for my efforts - we're all busy enough as it is, right?
To comply with the PCI-DSS best practices outlined above, depending on the solution chosen, managers might find themselves a having to stitch together a patchwork of different courses to cover all languages and frameworks used across the business, and that's when things get very messy, not to mention difficult for AppSec and compliance teams to assess as making an impact on security and vulnerability reduction in software. Work together to find the right fit, instead of rushing into the wrong option chasing a fast result. Otherwise, you might end up with a Frankenstein training solution... and that looks very scary.
Thanks for checking out part one of this PCI-DSS mini-series. In the final chapter, we will discuss how CISOs and CTOs can help this culture transformation, enable teams, and how the security front lines " your developer cohort " can use PCI-DSS awareness and compliance to their advantage.
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
Resources to get you started
OWASP Top 10 For LLM Applications: What’s New, Changed, and How to Stay Secure
Stay ahead in securing LLM applications with the latest OWASP Top 10 updates. Discover what's new, what’s changed, and how Secure Code Warrior equips you with up-to-date learning resources to mitigate risks in Generative AI.
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.