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
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
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.
Deep Dive: Navigating the Critical CUPS Vulnerability in GNU-Linux Systems
Discover the latest security challenges facing Linux users as we explore recent high-severity vulnerabilities in the Common UNIX Printing System (CUPS). Learn how these issues may lead to potential Remote Code Execution (RCE) and what you can do to protect your systems.
Coders Conquer Security: Share & Learn - Cross-Site Scripting (XSS)
Cross-site scripting (XSS) uses the trust of browsers and ignorance of users to steal data, take over accounts, and deface websites; it's a vulnerability that can get very ugly, very quickly. Let's take a look at how XSS works, what damage can be done, and how to prevent it.
