Coders Conquer Security Infrastructure as Code Series: Missing Function Level Access Control
It's time for the next installment of our Infrastructure as Code series, the blogs that will take developers like you to a whole new level of security awareness when deploying secure infrastructure within your own organization.
Oh, by the way... how did you fare with the security misconfiguration challenge in the previous blog? If you want to go ahead and tackle a missing functional level access control vulnerability right now, head on over to the platform:
(The link above will take you to the Kubernetes challenge, but once youre on the platform, use the drop-down to choose from Ansible, CloudFormation, Terraform or Docker as well. Your choice.)
Almost every application deployed today has some kind of access control mechanism that checks to see whether or not a user has permission to perform the requested functions. It's pretty much the cornerstone of good security, as well as functionality, when creating an application. In fact, all web applications need access controls in order to allow users with different privileges to use the program.
Problems can occur however when those same verification functions for access control are not performed at the infrastructure level, or are misconfigured. Without infrastructure-level access control in perfect order, it opens up an entire enterprise to hackers, who can use that vulnerability as their gateway for either unauthorized snooping or a full attack.
In fact, exploiting missing or misconfigured function access control vulnerabilities is extremely easy. Attackers don't even need to be overly skilled. They just need to know what commands execute functions within whatever framework is supporting the application. If they do, it's just a matter of trial and error. They can continually submit requests that shouldn't be allowed, and as soon as one succeeds, the targeted website, application, server, or even the entire network could be exposed.
How Do Missing Function Level Access Control Exploits Work?
There are a few ways that function level access controls can creep into an organization. For example, function level access can be left to an application and not verified by the underlying infrastructure. Or, infrastructure-level access control can be misconfigured. In some cases, administrators assume that non-authorized users won't know how to get to infrastructure resources that only higher-level users should be able to see and use a "security by obscurity" model which rarely works.
For an example of security by obscurity, the following URL is likely vulnerable to attack:
http://companywebsite.com/app/NormalUserHomepage
If an authenticated user employs a technique called Forced URL Browsing, they could try to reach a page that is only shown to administrators. An example might be:
http://companywebsite.com/app/AdminPages
If no server-side verification exists, they will simply be shown the admin pages (if its name matches the request) and will then have access to whatever additional functions that administrators do from the new page. If the server returns a "page not found" error to the attacker, they can simply keep trying until they figure out whatever name the admin page is given.
For attackers, exploiting missing function level access controls is a similar process. Instead of trying to browse unauthorized pages, they instead send in function requests. For example, they might try to create a new user with administrator rights. So their request would look something like this, depending on the framework:
POST/action/createuser name=hacker&pw=password&role=admin
If no function level access control exists, then the example above would be successful and a new administrator account would be created. Once the attacker logs back in as the new administrator, they would have the same access and permissions as any other administrator on that network or server.
The Fix for Missing Function Level Access Controls
Because it's so easy for attackers to exploit missing function level access control vulnerabilities, it's critical that they are found, fixed, and prevented. Thankfully, this is not overly difficult with some know-how and basic Infrastructure as Code security training.
The main protection will come from implementing role-based authorization at the infrastructure level. Never trust applications to handle that function. Even if they do, having infrastructure-side authorization will ensure that nothing is missed. Ideally, the authorization should come from a centralized location (for example, AWS IAM, Azure IAM, etc.) that is built into your organization's routine and applied to every new application. These authorization processes can come from the framework itself or any number of easy-to-use external modules.
Finally, your organization should embrace the concept of least privilege. All actions and functions should be denied by default, with the authorization process used to give valid users permission to do whatever they need. They should only be given enough permission to perform the required function, and only for as long as required.
Having missing function level access controls can be devastating. But thankfully, by building good infrastructure-level authorization practices into your organization, you can easily prevent this problem from ever happening.
Think you're ready to spot an access control bug in the wild? Compare these Docker code snippets; one vulnerable, one secure:
Vulnerable:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
Secure:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
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.
And if you missed it earlier, you can try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
Stay tuned for the next chapter!
Without infrastructure-level access control in perfect order, it opens up an entire enterprise to attackers, who can use that vulnerability as their gateway for either unauthorized snooping or a full attack.
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.
It's time for the next installment of our Infrastructure as Code series, the blogs that will take developers like you to a whole new level of security awareness when deploying secure infrastructure within your own organization.
Oh, by the way... how did you fare with the security misconfiguration challenge in the previous blog? If you want to go ahead and tackle a missing functional level access control vulnerability right now, head on over to the platform:
(The link above will take you to the Kubernetes challenge, but once youre on the platform, use the drop-down to choose from Ansible, CloudFormation, Terraform or Docker as well. Your choice.)
Almost every application deployed today has some kind of access control mechanism that checks to see whether or not a user has permission to perform the requested functions. It's pretty much the cornerstone of good security, as well as functionality, when creating an application. In fact, all web applications need access controls in order to allow users with different privileges to use the program.
Problems can occur however when those same verification functions for access control are not performed at the infrastructure level, or are misconfigured. Without infrastructure-level access control in perfect order, it opens up an entire enterprise to hackers, who can use that vulnerability as their gateway for either unauthorized snooping or a full attack.
In fact, exploiting missing or misconfigured function access control vulnerabilities is extremely easy. Attackers don't even need to be overly skilled. They just need to know what commands execute functions within whatever framework is supporting the application. If they do, it's just a matter of trial and error. They can continually submit requests that shouldn't be allowed, and as soon as one succeeds, the targeted website, application, server, or even the entire network could be exposed.
How Do Missing Function Level Access Control Exploits Work?
There are a few ways that function level access controls can creep into an organization. For example, function level access can be left to an application and not verified by the underlying infrastructure. Or, infrastructure-level access control can be misconfigured. In some cases, administrators assume that non-authorized users won't know how to get to infrastructure resources that only higher-level users should be able to see and use a "security by obscurity" model which rarely works.
For an example of security by obscurity, the following URL is likely vulnerable to attack:
http://companywebsite.com/app/NormalUserHomepage
If an authenticated user employs a technique called Forced URL Browsing, they could try to reach a page that is only shown to administrators. An example might be:
http://companywebsite.com/app/AdminPages
If no server-side verification exists, they will simply be shown the admin pages (if its name matches the request) and will then have access to whatever additional functions that administrators do from the new page. If the server returns a "page not found" error to the attacker, they can simply keep trying until they figure out whatever name the admin page is given.
For attackers, exploiting missing function level access controls is a similar process. Instead of trying to browse unauthorized pages, they instead send in function requests. For example, they might try to create a new user with administrator rights. So their request would look something like this, depending on the framework:
POST/action/createuser name=hacker&pw=password&role=admin
If no function level access control exists, then the example above would be successful and a new administrator account would be created. Once the attacker logs back in as the new administrator, they would have the same access and permissions as any other administrator on that network or server.
The Fix for Missing Function Level Access Controls
Because it's so easy for attackers to exploit missing function level access control vulnerabilities, it's critical that they are found, fixed, and prevented. Thankfully, this is not overly difficult with some know-how and basic Infrastructure as Code security training.
The main protection will come from implementing role-based authorization at the infrastructure level. Never trust applications to handle that function. Even if they do, having infrastructure-side authorization will ensure that nothing is missed. Ideally, the authorization should come from a centralized location (for example, AWS IAM, Azure IAM, etc.) that is built into your organization's routine and applied to every new application. These authorization processes can come from the framework itself or any number of easy-to-use external modules.
Finally, your organization should embrace the concept of least privilege. All actions and functions should be denied by default, with the authorization process used to give valid users permission to do whatever they need. They should only be given enough permission to perform the required function, and only for as long as required.
Having missing function level access controls can be devastating. But thankfully, by building good infrastructure-level authorization practices into your organization, you can easily prevent this problem from ever happening.
Think you're ready to spot an access control bug in the wild? Compare these Docker code snippets; one vulnerable, one secure:
Vulnerable:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
Secure:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
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.
And if you missed it earlier, you can try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
Stay tuned for the next chapter!
It's time for the next installment of our Infrastructure as Code series, the blogs that will take developers like you to a whole new level of security awareness when deploying secure infrastructure within your own organization.
Oh, by the way... how did you fare with the security misconfiguration challenge in the previous blog? If you want to go ahead and tackle a missing functional level access control vulnerability right now, head on over to the platform:
(The link above will take you to the Kubernetes challenge, but once youre on the platform, use the drop-down to choose from Ansible, CloudFormation, Terraform or Docker as well. Your choice.)
Almost every application deployed today has some kind of access control mechanism that checks to see whether or not a user has permission to perform the requested functions. It's pretty much the cornerstone of good security, as well as functionality, when creating an application. In fact, all web applications need access controls in order to allow users with different privileges to use the program.
Problems can occur however when those same verification functions for access control are not performed at the infrastructure level, or are misconfigured. Without infrastructure-level access control in perfect order, it opens up an entire enterprise to hackers, who can use that vulnerability as their gateway for either unauthorized snooping or a full attack.
In fact, exploiting missing or misconfigured function access control vulnerabilities is extremely easy. Attackers don't even need to be overly skilled. They just need to know what commands execute functions within whatever framework is supporting the application. If they do, it's just a matter of trial and error. They can continually submit requests that shouldn't be allowed, and as soon as one succeeds, the targeted website, application, server, or even the entire network could be exposed.
How Do Missing Function Level Access Control Exploits Work?
There are a few ways that function level access controls can creep into an organization. For example, function level access can be left to an application and not verified by the underlying infrastructure. Or, infrastructure-level access control can be misconfigured. In some cases, administrators assume that non-authorized users won't know how to get to infrastructure resources that only higher-level users should be able to see and use a "security by obscurity" model which rarely works.
For an example of security by obscurity, the following URL is likely vulnerable to attack:
http://companywebsite.com/app/NormalUserHomepage
If an authenticated user employs a technique called Forced URL Browsing, they could try to reach a page that is only shown to administrators. An example might be:
http://companywebsite.com/app/AdminPages
If no server-side verification exists, they will simply be shown the admin pages (if its name matches the request) and will then have access to whatever additional functions that administrators do from the new page. If the server returns a "page not found" error to the attacker, they can simply keep trying until they figure out whatever name the admin page is given.
For attackers, exploiting missing function level access controls is a similar process. Instead of trying to browse unauthorized pages, they instead send in function requests. For example, they might try to create a new user with administrator rights. So their request would look something like this, depending on the framework:
POST/action/createuser name=hacker&pw=password&role=admin
If no function level access control exists, then the example above would be successful and a new administrator account would be created. Once the attacker logs back in as the new administrator, they would have the same access and permissions as any other administrator on that network or server.
The Fix for Missing Function Level Access Controls
Because it's so easy for attackers to exploit missing function level access control vulnerabilities, it's critical that they are found, fixed, and prevented. Thankfully, this is not overly difficult with some know-how and basic Infrastructure as Code security training.
The main protection will come from implementing role-based authorization at the infrastructure level. Never trust applications to handle that function. Even if they do, having infrastructure-side authorization will ensure that nothing is missed. Ideally, the authorization should come from a centralized location (for example, AWS IAM, Azure IAM, etc.) that is built into your organization's routine and applied to every new application. These authorization processes can come from the framework itself or any number of easy-to-use external modules.
Finally, your organization should embrace the concept of least privilege. All actions and functions should be denied by default, with the authorization process used to give valid users permission to do whatever they need. They should only be given enough permission to perform the required function, and only for as long as required.
Having missing function level access controls can be devastating. But thankfully, by building good infrastructure-level authorization practices into your organization, you can easily prevent this problem from ever happening.
Think you're ready to spot an access control bug in the wild? Compare these Docker code snippets; one vulnerable, one secure:
Vulnerable:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
Secure:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
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.
And if you missed it earlier, you can try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
Stay tuned for the next chapter!
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.
It's time for the next installment of our Infrastructure as Code series, the blogs that will take developers like you to a whole new level of security awareness when deploying secure infrastructure within your own organization.
Oh, by the way... how did you fare with the security misconfiguration challenge in the previous blog? If you want to go ahead and tackle a missing functional level access control vulnerability right now, head on over to the platform:
(The link above will take you to the Kubernetes challenge, but once youre on the platform, use the drop-down to choose from Ansible, CloudFormation, Terraform or Docker as well. Your choice.)
Almost every application deployed today has some kind of access control mechanism that checks to see whether or not a user has permission to perform the requested functions. It's pretty much the cornerstone of good security, as well as functionality, when creating an application. In fact, all web applications need access controls in order to allow users with different privileges to use the program.
Problems can occur however when those same verification functions for access control are not performed at the infrastructure level, or are misconfigured. Without infrastructure-level access control in perfect order, it opens up an entire enterprise to hackers, who can use that vulnerability as their gateway for either unauthorized snooping or a full attack.
In fact, exploiting missing or misconfigured function access control vulnerabilities is extremely easy. Attackers don't even need to be overly skilled. They just need to know what commands execute functions within whatever framework is supporting the application. If they do, it's just a matter of trial and error. They can continually submit requests that shouldn't be allowed, and as soon as one succeeds, the targeted website, application, server, or even the entire network could be exposed.
How Do Missing Function Level Access Control Exploits Work?
There are a few ways that function level access controls can creep into an organization. For example, function level access can be left to an application and not verified by the underlying infrastructure. Or, infrastructure-level access control can be misconfigured. In some cases, administrators assume that non-authorized users won't know how to get to infrastructure resources that only higher-level users should be able to see and use a "security by obscurity" model which rarely works.
For an example of security by obscurity, the following URL is likely vulnerable to attack:
http://companywebsite.com/app/NormalUserHomepage
If an authenticated user employs a technique called Forced URL Browsing, they could try to reach a page that is only shown to administrators. An example might be:
http://companywebsite.com/app/AdminPages
If no server-side verification exists, they will simply be shown the admin pages (if its name matches the request) and will then have access to whatever additional functions that administrators do from the new page. If the server returns a "page not found" error to the attacker, they can simply keep trying until they figure out whatever name the admin page is given.
For attackers, exploiting missing function level access controls is a similar process. Instead of trying to browse unauthorized pages, they instead send in function requests. For example, they might try to create a new user with administrator rights. So their request would look something like this, depending on the framework:
POST/action/createuser name=hacker&pw=password&role=admin
If no function level access control exists, then the example above would be successful and a new administrator account would be created. Once the attacker logs back in as the new administrator, they would have the same access and permissions as any other administrator on that network or server.
The Fix for Missing Function Level Access Controls
Because it's so easy for attackers to exploit missing function level access control vulnerabilities, it's critical that they are found, fixed, and prevented. Thankfully, this is not overly difficult with some know-how and basic Infrastructure as Code security training.
The main protection will come from implementing role-based authorization at the infrastructure level. Never trust applications to handle that function. Even if they do, having infrastructure-side authorization will ensure that nothing is missed. Ideally, the authorization should come from a centralized location (for example, AWS IAM, Azure IAM, etc.) that is built into your organization's routine and applied to every new application. These authorization processes can come from the framework itself or any number of easy-to-use external modules.
Finally, your organization should embrace the concept of least privilege. All actions and functions should be denied by default, with the authorization process used to give valid users permission to do whatever they need. They should only be given enough permission to perform the required function, and only for as long as required.
Having missing function level access controls can be devastating. But thankfully, by building good infrastructure-level authorization practices into your organization, you can easily prevent this problem from ever happening.
Think you're ready to spot an access control bug in the wild? Compare these Docker code snippets; one vulnerable, one secure:
Vulnerable:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER root
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
Secure:
FROM quay.io/prometheus/busybox:latest
ARG VERSION=0.12.1
ARG FILENAME=mysqld_exporter-${VERSION}.linux-amd64
ARG URL=https://github.com/prometheus/mysqld_exporter/releases/download/v
RUN wget $URL$VERSION/$FILENAME.tar.gz && \
tar -xvf $FILENAME.tar.gz && \
mv $FILENAME/mysqld_exporter /bin/mysqld_exporter
COPY .my.cnf /home/.my.cnf
COPY ./scripts/entrypoint.sh ~/entrypoint.sh
USER nobody
EXPOSE 9104
ENTRYPOINT [ "sh", "~/entrypoint.sh" ]
CMD [ "/bin/mysqld_exporter" ]
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.
And if you missed it earlier, you can try an IaC gamified security challenge on the Secure Code Warrior platform to keep all your cybersecurity skills honed and up to date.
Stay tuned for the next chapter!
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.
