Coders Conquer Security Infrastructure as Code Series: Insufficient Transport Layer Protection
If you're a developer looking to learn more about the steps you can take to begin deploying secure infrastructure as code (IaC) in your organization, then you've come to the right place. This is the next chapter in our IaC series, designed to level you up in IaC security best practices.
Before we start, how did you fare with the challenge from the last installment? If you have mastered insecure cryptography, let's see how you go with insufficient transport layer protection before we dig into the details:
Want to learn more and achieve a perfect score? Read on:
In our last article, we talked about the importance of having secure cryptography to protect any important or personal data stored by applications and programs. If you have strong encryption, it acts as a perfect last line of defense. Even if an attacker is able to steal that data, if it's strongly encrypted, then the information locked inside those files is still protected.
Protecting data at rest, however, is only one part of a complete data defense. Whenever valid users need to access protected data, it has to be sent to them. At times, applications will also share data with other programs as part of an overall workload. Unless the transport layer is protected, it makes it vulnerable to both outside snooping and unauthorized internal viewing. As such, having insufficient transport layer protection can cause serious issues.
It's a common problem. The OWASP security organization even maintains a full page about insufficient transport layer protection.
Why is insufficient transport layer protection dangerous?
If you don't sufficiently protect your transport layers, then it's relatively easy for skilled hackers to intercept information flowing between your users and your applications using techniques like man-in-the-middle attacks. Probably the most dangerous aspect of this kind of snooping is that it's almost completely invisible to any internal cybersecurity platforms or scans because it occurs outside of your network and your control.
For example, in a Docker environment deploying an Nginx service:
services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target: /etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy: *default-restart_policy
resources: *default-resources_policy
The Nginx service configuration will not encrypt or protect the connection, making all information exchanged through the link vulnerable to a variety of attacks or snooping.
server {
server_name scw-dev-blog.org;
listen 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Often times, the first signal that someone might be snooping through your transport layers is when a large number of stolen user passwords are used in subsequent attacks. If other data like customer information, financial records or important company secrets are stolen via an insecure transport layer, you may never even realize that you have been compromised.
And it's not just the transport layer between users and applications that requires protection. On the backend, many applications communicate with one another and with servers farther along in the workflow chain. While these internal communications are generally not vulnerable to outside snooping, it can expose data to users who may be allowed on the network but not authorized to see certain highly-protected or sensitive information.
Properly securing transport layers for total data protection
Protecting transport layers is best done while applications are being created. This process begins with having a secure backend infrastructure. For websites, everything should be done using HTTPS. Never mix HTTP and HTTPS infrastructure. You should even set your sites to automatically route unsecured HTTP requests over to the HTTPS infrastructure.
In the example from above, a proper method of protecting the transport layer would be:
server {
server_name scw-dev-blog.org;
listen 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
In that example, all connections with the Nginx service are strongly encrypted. The server section of the Nginx configuration only includes listen 8443 ssl in order to force SSL to protect connections.
To protect your data from insider threats, developers should employ a strong transport layer encryption protocol like TLS 1.2. Once you have TLS 1.2 or its equivalent in place, weaker protocols like SSL v2 should be completely removed from your infrastructure and automatically barred from ever being used.
And always keep in mind that securing an application isn't fully complete until both the data at rest and the transport layers are sufficiently protected. That way you can guarantee complete end-to-end protection for data both internally and when flowing to authorized external users.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
At times, applications will also share data with other programs as part of an overall workload. Unless the transport layer is protected, it makes it vulnerable to both outside snooping and unauthorized internal viewing.
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.
If you're a developer looking to learn more about the steps you can take to begin deploying secure infrastructure as code (IaC) in your organization, then you've come to the right place. This is the next chapter in our IaC series, designed to level you up in IaC security best practices.
Before we start, how did you fare with the challenge from the last installment? If you have mastered insecure cryptography, let's see how you go with insufficient transport layer protection before we dig into the details:
Want to learn more and achieve a perfect score? Read on:
In our last article, we talked about the importance of having secure cryptography to protect any important or personal data stored by applications and programs. If you have strong encryption, it acts as a perfect last line of defense. Even if an attacker is able to steal that data, if it's strongly encrypted, then the information locked inside those files is still protected.
Protecting data at rest, however, is only one part of a complete data defense. Whenever valid users need to access protected data, it has to be sent to them. At times, applications will also share data with other programs as part of an overall workload. Unless the transport layer is protected, it makes it vulnerable to both outside snooping and unauthorized internal viewing. As such, having insufficient transport layer protection can cause serious issues.
It's a common problem. The OWASP security organization even maintains a full page about insufficient transport layer protection.
Why is insufficient transport layer protection dangerous?
If you don't sufficiently protect your transport layers, then it's relatively easy for skilled hackers to intercept information flowing between your users and your applications using techniques like man-in-the-middle attacks. Probably the most dangerous aspect of this kind of snooping is that it's almost completely invisible to any internal cybersecurity platforms or scans because it occurs outside of your network and your control.
For example, in a Docker environment deploying an Nginx service:
services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target: /etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy: *default-restart_policy
resources: *default-resources_policy
The Nginx service configuration will not encrypt or protect the connection, making all information exchanged through the link vulnerable to a variety of attacks or snooping.
server {
server_name scw-dev-blog.org;
listen 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Often times, the first signal that someone might be snooping through your transport layers is when a large number of stolen user passwords are used in subsequent attacks. If other data like customer information, financial records or important company secrets are stolen via an insecure transport layer, you may never even realize that you have been compromised.
And it's not just the transport layer between users and applications that requires protection. On the backend, many applications communicate with one another and with servers farther along in the workflow chain. While these internal communications are generally not vulnerable to outside snooping, it can expose data to users who may be allowed on the network but not authorized to see certain highly-protected or sensitive information.
Properly securing transport layers for total data protection
Protecting transport layers is best done while applications are being created. This process begins with having a secure backend infrastructure. For websites, everything should be done using HTTPS. Never mix HTTP and HTTPS infrastructure. You should even set your sites to automatically route unsecured HTTP requests over to the HTTPS infrastructure.
In the example from above, a proper method of protecting the transport layer would be:
server {
server_name scw-dev-blog.org;
listen 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
In that example, all connections with the Nginx service are strongly encrypted. The server section of the Nginx configuration only includes listen 8443 ssl in order to force SSL to protect connections.
To protect your data from insider threats, developers should employ a strong transport layer encryption protocol like TLS 1.2. Once you have TLS 1.2 or its equivalent in place, weaker protocols like SSL v2 should be completely removed from your infrastructure and automatically barred from ever being used.
And always keep in mind that securing an application isn't fully complete until both the data at rest and the transport layers are sufficiently protected. That way you can guarantee complete end-to-end protection for data both internally and when flowing to authorized external users.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
If you're a developer looking to learn more about the steps you can take to begin deploying secure infrastructure as code (IaC) in your organization, then you've come to the right place. This is the next chapter in our IaC series, designed to level you up in IaC security best practices.
Before we start, how did you fare with the challenge from the last installment? If you have mastered insecure cryptography, let's see how you go with insufficient transport layer protection before we dig into the details:
Want to learn more and achieve a perfect score? Read on:
In our last article, we talked about the importance of having secure cryptography to protect any important or personal data stored by applications and programs. If you have strong encryption, it acts as a perfect last line of defense. Even if an attacker is able to steal that data, if it's strongly encrypted, then the information locked inside those files is still protected.
Protecting data at rest, however, is only one part of a complete data defense. Whenever valid users need to access protected data, it has to be sent to them. At times, applications will also share data with other programs as part of an overall workload. Unless the transport layer is protected, it makes it vulnerable to both outside snooping and unauthorized internal viewing. As such, having insufficient transport layer protection can cause serious issues.
It's a common problem. The OWASP security organization even maintains a full page about insufficient transport layer protection.
Why is insufficient transport layer protection dangerous?
If you don't sufficiently protect your transport layers, then it's relatively easy for skilled hackers to intercept information flowing between your users and your applications using techniques like man-in-the-middle attacks. Probably the most dangerous aspect of this kind of snooping is that it's almost completely invisible to any internal cybersecurity platforms or scans because it occurs outside of your network and your control.
For example, in a Docker environment deploying an Nginx service:
services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target: /etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy: *default-restart_policy
resources: *default-resources_policy
The Nginx service configuration will not encrypt or protect the connection, making all information exchanged through the link vulnerable to a variety of attacks or snooping.
server {
server_name scw-dev-blog.org;
listen 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Often times, the first signal that someone might be snooping through your transport layers is when a large number of stolen user passwords are used in subsequent attacks. If other data like customer information, financial records or important company secrets are stolen via an insecure transport layer, you may never even realize that you have been compromised.
And it's not just the transport layer between users and applications that requires protection. On the backend, many applications communicate with one another and with servers farther along in the workflow chain. While these internal communications are generally not vulnerable to outside snooping, it can expose data to users who may be allowed on the network but not authorized to see certain highly-protected or sensitive information.
Properly securing transport layers for total data protection
Protecting transport layers is best done while applications are being created. This process begins with having a secure backend infrastructure. For websites, everything should be done using HTTPS. Never mix HTTP and HTTPS infrastructure. You should even set your sites to automatically route unsecured HTTP requests over to the HTTPS infrastructure.
In the example from above, a proper method of protecting the transport layer would be:
server {
server_name scw-dev-blog.org;
listen 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
In that example, all connections with the Nginx service are strongly encrypted. The server section of the Nginx configuration only includes listen 8443 ssl in order to force SSL to protect connections.
To protect your data from insider threats, developers should employ a strong transport layer encryption protocol like TLS 1.2. Once you have TLS 1.2 or its equivalent in place, weaker protocols like SSL v2 should be completely removed from your infrastructure and automatically barred from ever being used.
And always keep in mind that securing an application isn't fully complete until both the data at rest and the transport layers are sufficiently protected. That way you can guarantee complete end-to-end protection for data both internally and when flowing to authorized external users.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
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.
If you're a developer looking to learn more about the steps you can take to begin deploying secure infrastructure as code (IaC) in your organization, then you've come to the right place. This is the next chapter in our IaC series, designed to level you up in IaC security best practices.
Before we start, how did you fare with the challenge from the last installment? If you have mastered insecure cryptography, let's see how you go with insufficient transport layer protection before we dig into the details:
Want to learn more and achieve a perfect score? Read on:
In our last article, we talked about the importance of having secure cryptography to protect any important or personal data stored by applications and programs. If you have strong encryption, it acts as a perfect last line of defense. Even if an attacker is able to steal that data, if it's strongly encrypted, then the information locked inside those files is still protected.
Protecting data at rest, however, is only one part of a complete data defense. Whenever valid users need to access protected data, it has to be sent to them. At times, applications will also share data with other programs as part of an overall workload. Unless the transport layer is protected, it makes it vulnerable to both outside snooping and unauthorized internal viewing. As such, having insufficient transport layer protection can cause serious issues.
It's a common problem. The OWASP security organization even maintains a full page about insufficient transport layer protection.
Why is insufficient transport layer protection dangerous?
If you don't sufficiently protect your transport layers, then it's relatively easy for skilled hackers to intercept information flowing between your users and your applications using techniques like man-in-the-middle attacks. Probably the most dangerous aspect of this kind of snooping is that it's almost completely invisible to any internal cybersecurity platforms or scans because it occurs outside of your network and your control.
For example, in a Docker environment deploying an Nginx service:
services:
nginx:
image: localhost:5000/scw_nginx
build: ./nginx
secrets:
- nginx_cert
- nginx_key
volumes:
- type: bind
source: ./nginx/nginx.conf
target: /etc/nginx/nginx.conf
read_only: yes
ports:
- 80:8443
networks:
- frontend
deploy:
restart_policy: *default-restart_policy
resources: *default-resources_policy
The Nginx service configuration will not encrypt or protect the connection, making all information exchanged through the link vulnerable to a variety of attacks or snooping.
server {
server_name scw-dev-blog.org;
listen 8443;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Often times, the first signal that someone might be snooping through your transport layers is when a large number of stolen user passwords are used in subsequent attacks. If other data like customer information, financial records or important company secrets are stolen via an insecure transport layer, you may never even realize that you have been compromised.
And it's not just the transport layer between users and applications that requires protection. On the backend, many applications communicate with one another and with servers farther along in the workflow chain. While these internal communications are generally not vulnerable to outside snooping, it can expose data to users who may be allowed on the network but not authorized to see certain highly-protected or sensitive information.
Properly securing transport layers for total data protection
Protecting transport layers is best done while applications are being created. This process begins with having a secure backend infrastructure. For websites, everything should be done using HTTPS. Never mix HTTP and HTTPS infrastructure. You should even set your sites to automatically route unsecured HTTP requests over to the HTTPS infrastructure.
In the example from above, a proper method of protecting the transport layer would be:
server {
server_name scw-dev-blog.org;
listen 8443 ssl;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_prefer_server_ciphers on;
ssl_certificate /run/secrets/nginx_cert;
ssl_certificate_key /run/secrets/nginx_key;
access_log /dev/stdout;
error_log /dev/stderr;
location / {
proxy_pass http://wordpress:8080;
proxy_set_header Host $http_host;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
In that example, all connections with the Nginx service are strongly encrypted. The server section of the Nginx configuration only includes listen 8443 ssl in order to force SSL to protect connections.
To protect your data from insider threats, developers should employ a strong transport layer encryption protocol like TLS 1.2. Once you have TLS 1.2 or its equivalent in place, weaker protocols like SSL v2 should be completely removed from your infrastructure and automatically barred from ever being used.
And always keep in mind that securing an application isn't fully complete until both the data at rest and the transport layers are sufficiently protected. That way you can guarantee complete end-to-end protection for data both internally and when flowing to authorized external users.
Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.
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
Reactive Versus Preventive Security: Prevention Is a Better Cure
The idea of bringing preventive security to legacy code and systems at the same time as newer applications can seem daunting, but a Secure-by-Design approach, enforced by upskilling developers, can apply security best practices to those systems. It’s the best chance many organizations have of improving their security postures.
The Benefits of Benchmarking Security Skills for Developers
The growing focus on secure code and Secure-by-Design principles requires developers to be trained in cybersecurity from the start of the SDLC, with tools like Secure Code Warrior’s Trust Score helping measure and improve their progress.
Driving Meaningful Success for Enterprise Secure-by-Design Initiatives
Our latest research paper, Benchmarking Security Skills: Streamlining Secure-by-Design in the Enterprise is the result of deep analysis of real Secure-by-Design initiatives at the enterprise level, and deriving best practice approaches based on data-driven findings.
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.