Coders Conquer Security Infrastructure as Code Series: Disabled Security Features
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window.
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 demo
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.
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.
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
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 demo
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.
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.
Threats to cybersecurity these days are ubiquitous and relentless. As more facets of our lives are digitized, the higher the stakes for cybercriminals - there is too much code to keep secure, and private data is too valuable. And, well, trying to keep up with and defend every aspect of the attack surface after programs are deployed has become almost impossible.
There are approaches that can alleviate some of these symptoms, and one of them is apparent when shrewd organizations embrace the concept of Infrastructure as Code (IaC). Of course, as with any development, there are some security pitfalls to navigate. And since developers are working on the code that generates vital infrastructure to host applications, security awareness is critical at every stage of the process.
So, how exactly would a developer new to a cloud server environment go about upskilling, learning the ropes, and approaching the build with heightened security awareness? We have created the next Coders Conquer Security series to tackle common IaC vulnerabilities, and these next few blogs will focus on steps you, the developer, can take to begin deploying secure infrastructure as code in your own organization.
Let's get started.
There is a fable from the American Old West about a man who was paranoid that bandits would attack and rob his homestead. To compensate, he invested in all kinds of security like installing an extra-strong front door, boarding up all of his windows, and keeping lots of guns within easy reach. He was still robbed one night while he slept because he forgot to lock the side door. The bandits simply found the disabled security and quickly exploited the situation.
Having disabled security features in your infrastructure is a lot like that. Even if your network has a strong security infrastructure in place, it does very little good if elements have been disabled.
Let me pose a challenge before we dive in:
Visit the link above, and youll be transported to our gamified training platform, where you can attempt to defeat a disabled security feature vulnerability right now. (Heads up: It will open in Kubernetes, but use the drop-down menu and you can choose from Docker, CloudFormation, Terraform and Ansible).
How did you do? If you still have some work to do, read on:
Security functions can be disabled for a variety of reasons. With some applications and frameworks, they may be disabled by default and must first be turned on to start functioning. It's also possible that administrators have disabled specific security functions in order to more easily perform certain tasks without getting constantly challenged or blocked, (i.e. making an AWS S3 bucket public). After their work is complete, they may forget to reactivate those disabled functions. They might also prefer to leave them turned off to make their job easier in the future.
Why disabled security features are so dangerous
Having one or more disabled security features is bad for a couple of reasons. For one, the security feature was put into infrastructure resources to protect against a known exploit, threat, or vulnerability. If it's disabled, then it won't be able to protect your resources.
Attackers will always attempt to find easily exploitable vulnerabilities first and may even use a script to run through common weaknesses. It's not unlike a thief checking all the cars on a street to see if any doors are unlocked, which is a lot easier than smashing a window. Hackers might be surprised to find that a common security defense is inactive. But when that happens, it won't take them long to exploit it.
Secondly, having good security in place and then disabling creates a false sense of security. Administrators may think they are protected from common threats if they don't know that someone disabled those defenses.
As an example of how an attacker could take advantage of a disabled security feature, consider the AWS S3 security feature of block public access. With Amazon S3 block public access, account administrators and bucket owners can easily set up centralized controls to limit public access to their Amazon S3 resources. However, some administrators encountering problems when accessing the S3 bucket decide to make it public in order to complete the task as soon as possible. If they forget to enable that security feature, an attacker will have complete access to the information stored in that S3 bucket, causing not only information disclosure but also incurring extra costs due to data transfer charges.
Lets compare some real-world code; check out these CloudFormation snippets:
Vulnerable:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Secure:
CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"
Preventing disabled security features
Stopping disabled security features from negatively harming your organization is as much a matter of policy as practice. There should be a firm policy in place stating that security features should only be disabled under very specific circumstances. Incidents where features must be temporarily disabled to work on a problem or update applications should be logged. After the required work is complete, the features should be checked to ensure that they have been fully reactivated.
If a security function must be permanently disabled in order to streamline operations, other protections should be provided to affected data to ensure that hackers won't be able to access it in the absence of the default protection. If a needed protection feature has been disabled, it's only a matter of time before an attacker finds that unlocked door and exploits the situation.
Learn more, challenge yourself:
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and your customers from the ravages of other security flaws and vulnerabilities.
Ready to find and fix this vulnerability now youve read the post? Time to try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
This is a weekly series covering our top eight Infrastructure as Code vulnerabilities; check back next week for more!
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
10 Key Predictions: Secure Code Warrior on AI & Secure-by-Design’s Influence in 2025
Organizations are facing tough decisions on AI usage to support long-term productivity, sustainability, and security ROI. It’s become clear to us over the last few years that AI will never fully replace the role of the developer. From AI + developer partnerships to the increasing pressures (and confusion) around Secure-by-Design expectations, let’s take a closer look at what we can expect over the next year.
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.
.png)
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.
Developer-driven coding.
Securely.
Contact us today and make software security an intrinsic part of your development process.
