While most of the vulnerabilities on this list are pretty specific to APIs, the disabled security features/debug features enabled/improper permissions problem is one that can strike anywhere. It's likely a little more prevalent in APIs, but attackers will often attempt to find unpatched flaws and unprotected files or directories anywhere in a network. Coming across an API that has debugging enabled or security features disabled just makes their nefarious work a little easier. Worse yet, automated tools are available to detect and exploit security misconfigurations, so if you have them in your environment, there is a good chance that they will be exploited, which is why this vulnerability made the OWASP list of dangerous API flaws.

Before we get into the fun, see if you can solve this debug challenge:

How does the disabled security features/debug features enabled/improper permissions flaw sneak into an API?

To see how this multidimensional API flaw gets added to networks, we must break it down into its component parts. Let's start with the enabled debug features problem. Debugging is a useful tool that helps developers figure out why applications aren't performing correctly or making errors. With debugging enabled, errors and exceptions generate detailed error pages so developers can see what went wrong and fix problems. It's perfectly fine to have this active while an application is still in development.

However, there is a reason why most frameworks come with warnings about running debug mode in a production environment, likely right in the code where debugging is activated. For example:

# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = True

In this example, debugging has been activated. The Django application will generate detailed error pages when an exception is raised. If this is done in a production environment, an adversary would have access to these error pages, which includes metadata information about the environment. Although most frameworks have debugging turned off by default, it's easy to forget to switch it back off if activated during a long development process. Then when the application moves to a production environment, it provides attackers with a lot of information about how to compromise an application, or even an entire server or network.

While enabling debug mode is mostly a standalone problem, the improper permissions and disabled security features vulnerabilities often work together. For example, in a real scenario provided by OWASP, an attacker used a search engine to find a database that was accidentally connected to the internet. Because the popular database management system was using its default configuration, authentication was disabled. Thus, by combining the improper permissions and disabled security features vulnerabilities, the attacker gained access to millions of records with PII, personal preferences and authentication data.

Eliminating the disabled security features/debug features enabled/improper permissions vulnerabilities

You probably need to make a two-pronged approach in eliminating this vulnerability. To remove the enabled debug part of the problem, simply add a check to the development process to ensure that debugging is disabled before moving an API or application to the production environment. From our example, the proper command to do that would be as follows:

# SECURITY WARNING: dont run with debug turned on in production!
DEBUG = False

Now debug features in the Django application are disabled with the DEBUG flag configured to False. No error pages will be generated in response to errors. If an adversary still gains access to error pages, they won't contain any useful metadata, and won't pose a risk to the application.

Eliminating disabled security features and improper permissions vulnerabilities is a bit more difficult because they can encompass a wide range of specific vulnerabilities. The best way to stop them is to develop a standard and repeatable process to allow for the fast and easy deployment of locked down assets to the production environment.

Even then, you should create a process where orchestration files, API components, and cloud services like Amazon S3 bucket permissions are constantly reviewed and updated. This review should also rate the overall effectiveness of security settings across the entire environment over time to make sure the organization is always improving its API security.

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.

The mass assignment vulnerability was born because many modern frameworks encourage developers to use functions that automatically bind input from clients into code variables and internal objects. This is done to simplify code and speed up operations.

Attackers can use this methodology to force changes to object properties that should never be updated by a client. Normally this results in business-specific problems, like a user adding admin privileges to themselves as opposed to bringing down a website or stealing corporate secrets. Attackers must also have some idea of the relationships between objects and the business logic of the application they are exploiting.

However, none of that makes the mass assignment vulnerability any less dangerous in the hands of a clever and malicious user.

Before we launch into the full guide, play our gamified challenge and see how you fare:

How can attackers exploit the mass assignment vulnerability?

The scenario put forward by OWASP (and modified slightly by us) assumes a ride-sharing application that includes different properties bound to objects in the code using mass assignment. These include permission-related properties that users can change and process-dependent properties that should only be set internally by the application. Both use mass assignment to bind properties to objects.

In this scenario, the ride-sharing application allows users to update their profiles, as is common in many user-facing applications. This is done using an API call sent to PUT, which returns the following JSON object:

{"user_name":"SneakySnake", "age":17, "is_admin":false}

Because the attacker, Mr. SneakySnake in this case, has figured out the relationship between the properties and the objects, he can resend his original request to update his profile with the following string:

{"user_name":"SneakySnake","age":24,, "is_admin":true}

As the endpoint is vulnerable to mass assignment, it accepts the new input as valid. Not only did our hacker add a few years to his profile, but he also assigned himself admin privileges.

Eliminating the mass assignment vulnerability

As convenient as it might be to use the mass assignment function in some frameworks, you should avoid doing that if you want to keep your APIs secure. Instead, parse request values rather than binding them directly to an object. You can also use a reduced data transfer object which would provide nearly the same convenience as binding directly to the object itself, only without the associated risk.

As an extra precaution, sensitive properties like admin privileges from the example above could be denied so that they will never be accepted by the server on an API call. An even better idea might be to deny every property by default and then allow specific, non-sensitive ones that you want users to be able to update or change. Doing any of those things can help to lock down APIs and eliminate the mass assignment vulnerability from your environment.

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.

Add developer-centric training to industry-standard SARIF files, directly in GitHub code scanning workflows with our new GitHub Action.

On September 30th, GitHub officially announced the general availability of GitHub code scanning. GitHub code scanning is a developer-first, GitHub-native approach to easily finding security vulnerabilities before they reach production.

Code scanning integrates with GitHub Actions " or an existing CI/CD environment " to maximize flexibility for development teams. It scans code as it's created, surfacing actionable security reviews within pull requests, and automating security as a part of a GitHub workflow.

A seamless approach to security for developers.

Built on the open SARIF (Static Analysis Results Interchange Format) standard, code scanning is designed to flex with the ever-growing needs of organization, so they can include things like open-source and commercial static application security testing (SAST) solutions within the same GitHub-native experience.

Third-party code scanning tools can be initiated with a GitHub Action or a GitHub App based on an event in GitHub itself, like a pull request. The results are formatted as SARIF and uploaded to the GitHub Security Alerts tab. Alerts are then aggregated per tool, and GitHub can track and suppress duplicate alerts. This allows developers to use their tool of choice for any of their projects on GitHub, all within the native GitHub experience. Quite simply, it cuts through the disruption of some traditional approaches to security, and it respects the developer workflow.

Yesterday, Secure Code Warrior was featured by GitHub as the only developer-centric training provider in their blog post, Third-Party Code Scanning Tools: Static Analysis & Developer Security Training, alongside Synk, Checkmarx, Fortify On Demand, Synopsis and Veracode.

While many SCA/SAST solutions provide lots of details for each of the vulnerabilities discovered, and references to published advisories and associated CWEs, not every developer is a security expert, nor should that be expected of them. Practical, usable advice and tools are the key to actionable awareness.

Contextual micro-learning.

The more context developers have for vulnerabilities, the more they're able to understand the risks, prioritize fixing the most pressing issues and ultimately prevent them in the first place. That's where Secure Code Warrior comes in. Our mission is to empower developers to write secure code from the very beginning through fun, engaging, and framework-specific training, helping them think and code with a security mindset to achieve rapid improvements in security compliance, consistency, quality and development speed.

GitHub code scanning integration

Secure Code Warrior has built a GitHub Action that brings contextual learning to GitHub code scanning. This means developers can use a third-party action like the Snyk Container Action to find vulnerabilities, and then augment the output with CWE-specific, hyper-relevant learning.

The Secure Code Warrior GitHub Action processes an industry-standard SARIF file and appends contextual learning based upon CWE references in a SARIF rule object. This empowers development and security teams to not only find vulnerabilities, but enrich supported SAST tool reports with actionable knowledge that helps them prevent vulnerabilities from reoccurring.

Ready to try it out for yourself?

Get the action for free directly from the GitHub Marketplace here.
Learn more about the Secure Code Warrior GitHub Action here.

This series of blogs will focus on some of the worst vulnerabilities as they relate to Application Programming Interfaces (APIs). These are so bad that they made the Open Web Application Security Project (OWASP) list of top API vulnerabilities. Given how important APIs are to modern computing infrastructures, these are critical problems that you need to keep out of your applications and programs at all costs.

The missing function level access control vulnerability allows users to perform functions that should be restricted, or lets them access resources that should be protected. Normally, functions and resources are directly protected in the code or by configuration settings, but it's not always easy to do correctly. Implementing proper checks can be difficult because modern applications often contain many types of roles and groups, plus a complex user hierarchy.

But first, why not jump in and play our gamified challenge to see where you're at with navigating this tricky class of bug?

Let's take a more in-depth look:

APIs are especially vulnerable to this flaw because they are highly structured. Attackers who understand code can make educated guesses about how to implement commands that should be restricted to them. That is one of the main reasons why the function/resource level access control vulnerability made the OWASP top ten.

How can attackers exploit the function level access control vulnerability?

Attackers who suspect that functions or resources are not properly protected must first gain access to the system they want to attack. To exploit this vulnerability, they must have permission to send legitimate API calls to the endpoint. Perhaps there is a low-level guest access function or some way to join anonymously as part of the application's function. Once that access has been established, they can start changing commands in their legitimate API calls. For example, they might swap out GET with PUT, or change the USERS string in the URL to ADMINS. Again, because APIs are structured, it's easy to guess which commands might be allowed, and where to put them in the string.

OWASP gives an example of this vulnerability of a registration process set up to allow new users to join a website. It would probably use an API GET call, like this:

GET /api/invites/{invite_guid}

The malicious user would get back a JSON with details about the invite, including the user's role and email. They could then change GET to POST and also elevate their invite from a user to an admin using the following API call:

POST /api/invites/new
{"email":"shadyguy@targetedsystem.com","role":"admin"}

Only admins should be able to send POST commands, but if they are not properly secured, the API will accept them as legitimate and execute whatever the attacker wants. In this case, the malicious user would be invited to join the system as a new administrator. After that, they could see and do anything that a legitimate administrator could, which would not be good.

Eliminating the function level access control vulnerability

Preventing this API vulnerability is especially important because it's not difficult for an attacker to find functions that are unprotected within a structured API. So long as they can get some level of access to an API, they can begin to map the structure of the code and create calls that will eventually be followed.

As such, all business-level functions must be protected using a role-based authorization method. Most frameworks offer centralized routines to make that happen. If your chosen framework doesn't, or if the routine it has is difficult to implement, there are many external modules that are built specifically for easy use. Whatever method you ultimately choose, be sure to implement the authorization on the server. Never try to secure functions from the client side.

When working to create function and resource level permissions, keep in mind that users should only be given permissions to do what they need and nothing more. As is always the case when coding APIs or anything else, practice the least privilege methodology. It will secure your environment and head off a lot of cybersecurity-related trouble down the road.

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.

In this most festive of annual occasions for cybersecurity professionals, National Cybersecurity Awareness Month is a time many companies utilize to reflect on, and appraise, the general security awareness heartbeat across the organization. And with 62% of business experiencing a phishing or social engineering attack in 2018 alone, the importance of ensuring every individual in the business -- whether in a security role or not -- has adequate cybersecurity awareness training cannot be overstated.

As an increasingly global event, the month represents a catch-all for discussing best practices, and the initiatives are deliberately surface-level. However, even organizations with robust security programs and in-house specialists can use this time to assess the more technical teams for what they need to become more security-aware in the context of their role.

For AppSec specialists, development team leads, and the more security-savvy members of the engineering cohort, it might feel a bit like being taught how to suck eggs, but it is these champions within the business that can push security and safety to new heights, company-wide.

How to elevate your Cybersecurity Awareness Month

This is a golden opportunity for the security team to extend something of an olive branch to the development team, perhaps in the form of inter-team activities and programs that can help developers feel more positive about security in the context of their work.

Some kick-off ideas include:

1. Help developers get the support they need to learn about secure coding. Not having the right tools for the job is a great way to feel justified in slam-dunking a task into the Too Hard Basket. If developers don't have the right training and tools to see security as a priority in the coding process, then it's no wonder so many teams are ill-equipped to keep common vulnerabilities out of their code.
   
   Use this month to understand what is missing in the development tech stack, which managers can work together to improve communication and increase security visibility, and who can continue advocating for and championing security going forward.
   
2. Host a "Lunch and Learn'event. The cybersecurity and development communities are, in general, brimming with incredibly generous people who are only too happy to share their expertise. Reach out to conference speakers, tech peers in other companies, or even local OWASP chapters, and see who might be able to come in and chat with the team, or record a webinar with someone in the organization. It's a relatively quick win, and it can be a huge benefit for up-and-coming developers to see different security career pathways in front of them.
   
3. Gather for some friendly competition. Learning about security is a lot more fun when you do something a little different and special. Secure coding tournaments are a great way to get developers testing their secure coding skills, and competing with their peers in a gamified environment. Get a fancy dress theme happening, and be creative with the teams (how about developers vs. their managers?). Order some pizza, drinks, get some energetic music pumping, and it can be an event to remember for the whole organization.

Giving back to the community: Download your free Secure Code Bootcamp app

I'm a developer myself, and it has always been the case that we search for what we can share and use for free. It's a point of pride to make some freeware that might help others, and this month is a good time to reflect on our roots and look at what we can provide to the community.

To that end, we're pleased to announce our new, free app, Secure Code Bootcamp. This is a pocket secure coding companion for coders who want to challenge themselves, progressively boosting their security awareness anywhere, anytime.

Download the app for iOS and Android now, and learn how to locate and identify OWASP vulnerabilities in Node.JS, Python:Django, Java:Spring, C# .NET: MVC:

With the lack of resources and rate limiting, API vulnerability acts almost exactly how it's described by the title. Every API has limited resources and computing power available to it depending on its environment. Most are also required to field requests from users or other programs asking it to perform its desired function. This vulnerability occurs when too many requests come in at the same time, and the API does not have enough computing resources to handle those requests. The API can then become unavailable or unresponsive to new requests.

APIs become vulnerable to this problem if their rate or resource limits are not set correctly, or if limits are left undefined in the code. An API can then be overloaded if, for example, a business experiences a particularly busy period. But it's also a security vulnerability, because threat actors can purposely overload unprotected APIs with requests in order to perform Denial of Service (DDoS) attacks.  

By the way, how are you doing with the API gamified challenges so far? If you want to try your skills in handling a rate limiting vulnerability right now, step into the arena:

Now, let's go a little deeper.

What are some examples of the lack of resources and rate limiting API vulnerability?

There are two ways that this vulnerability can sneak into an API. The first is when a coder simply doesn't define what the throttle rates should be for an API. There might be a default setting for throttle rates somewhere in the infrastructure, but relying on that is not a good policy. Instead, each API should have its rates set individually. This is especially true because APIs can have vastly different functions as well as available resources.

For example, an internal API designed to serve just a few users could have a very low throttle rate and work just fine. But a public-facing API that is part of a live eCommerce site would most likely need an exceptionally high rate defined to compensate for the possibility of a surge in simultaneous users. In both cases, the throttling rates should be defined based on the expected needs, the number of potential users, and the available computing power.

It might be tempting, especially with APIs that will most likely be very busy, to set the rates to unlimited in order to try and maximize performance. This could be accomplished with a simple bit of code (as an example, we'll use the Python Django REST framework):

"DEFAULT_THROTTLE_RATES: {
       "anon: None,
       "user: None

In that example, both anonymous users and those known to the system can contact the API an unlimited number of times without regard to the number of requests over time. This is a bad idea because no matter how much computing resources an API has available, attackers can deploy things like botnets to eventually slow it to a crawl or possibly knock it offline altogether. When that happens, valid users will be denied access and the attack will be successful.

Eliminating Lack of Resources and Rate Limiting Problems

Every API that is deployed by an organization should have its throttle rates defined in its code. This could include things like execution timeouts, maximum allowable memory, the number of records per page that can be returned to a user, or the number of processes permitted within a defined timeframe.

From the above example, instead of leaving the throttling rates wide open, they could be tightly defined with different rates for anonymous and known users.

"DEFAULT_THROTTLE_RATES: {
       "anon: config("THROTTLE_ANON, default=200/hour),
       "user: config("THROTTLE_USER, default=5000/hour)

In the new example, the API would limit anonymous users to making 200 requests per hour. Known users who are already vetted by the system are given more leeway at 5,000 requests per hour. But even they are limited to prevent an accidental overload at peak times or to compensate if a user account is compromised and used for a denial of service attack.

As a final good practice to consider, it's a good idea to display a notification to users when they have reached the throttling limits along with an explanation as to when those limits will be reset. That way, valid users will know why an application is rejecting their requests. This can also be helpful if valid users doing approved tasks are denied access to an API because it can signal operations personnel that the throttling needs to be increased.

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.

The excessive data exposure vulnerability is distinct from other API problems on the OWASP list, in that it involves a very specific kind of data. The actual mechanics behind the vulnerability are similar to others, but excessive data exposure, in this case, is defined as involving legally protected or highly sensitive data. This can include any personally identifiable information, which is often referred to as PII. Or it could involve payment card industry information, or PCI. Finally, excessive data exposure can include any information that is subject to privacy laws, such as the General Data Protection Regulation (GDPR) in Europe or the Health Insurance Portability and Accountability Act (HIPAA) in the United States.

As you might imagine, this is cause for deep concern, and it's imperative that savvy developers learn how to squash these bugs wherever possible. If you're already prepared to take on a data exposure dragon, head to our gamified challenge:

What was your score? Read on and learn more:

What are some examples of excessive data exposure?

One of the primary reasons that excessive data exposure happens is because developers and coders don't have enough insight into the kind of data that their applications will be using. Because of this, developers tend to utilize generic processes where all object properties are exposed to end-users.

Developers also sometimes assume that frontend components will perform data filtering before displaying any information to users. For most generic data, this is rarely a problem. But exposing legally protected or sensitive data to users as part of a session ID, for example, can lead to big problems from both a security and a legal standpoint.

As an example of how easily sensitive data can be accidentally shared, the OWASP report envisions a scenario where a security guard is given access to specific IOT-based cameras in a facility. Perhaps those cameras are watching over sealed and secure areas, while other cameras that view people are supposed to be restricted to guards or supervisors with higher permissions.

To give the guard access to authorized cameras, developers can use an API call like the following one.

/api/sites/111/cameras

In response, the app would send details about the cameras that the guard is able to see in the following format:

{ "id":"xxx","live_access_token":"xxxxbbbbb","building_id":"yyy"}

On the surface, this would appear to work just fine. The guard, who is using the graphical user interface on the app, would only see the camera feeds that they are authorized to view. The problem is that because of the generic code used, the actual API response would contain a full list of all cameras throughout the facility. Anyone sniffing the network who captures that data, or compromises the guard's account, would be able to discover the locations and nomenclature for every camera on the network. They could then access that data without restriction.

Eliminating Excessive Data Exposure

The biggest key to preventing excessive data exposure is an understanding of the data and the protections surrounding it. Creating generic APIs and leaving it up to the client to sort data before displaying it to users is a dangerous choice that leads to many preventable security breaches.

In addition to understanding the relevant data protections, it's also important to stop the process of sending everything to a user with generic APIs. For example, code such as to_json() and to_string() must be avoided. Instead, the code should specifically pick the properties that need to return to authorized users and exclusively send that information.

As a way to ensure that no protected data is being accidentally overshared, organizations should consider implementing a schema-based response validation mechanism as an extra layer of security. It should define and enforce data being returned by all API methods including rules for error reporting.

Finally, all data classified as containing PII or PCI, or information that is protected by regulations such as GDPR or HIPAA should be protected using strong encryption. That way, even if the location of that data slips out as part of an excessive data exposure vulnerability, there is a good secondary line of defense in place that should protect the data even if it lands in the hands of a malicious user or threat actor.

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.

It's no wonder that broken authentication made the OWASP list for API problems - authentication mechanisms are notoriously difficult to implement correctly. Also, attackers have a little bit of an advantage because by their very nature most authentication challenges must be exposed to users, giving attackers a chance to study them and look for patterns or vulnerabilities that they can exploit.

Finally, because authentication often acts as a gateway to both an application and potentially to the rest of a network, they are tempting targets for attackers. If an authentication process is broken or vulnerable, there is a good chance that attackers will discover that weakness and exploit it.

So, in this chapter, we're going to learn how to shut the bad guys out when it comes to authentication issues. If you want to test your skills first, head over and play our gamified challenge:

Want to improve your score? Stay with me while we break it down.

What are some examples of broken or misconfigured authentication?

One example where the problem might not be so obvious is when an authentication method is vulnerable to credential stuffing, or using lists of known usernames and passwords to break security. Even a normally very secure authorization method, like multifactor authentication, might be vulnerable if requests are not limited, throttled, or otherwise monitored.

For example, an attacker could trigger a password recovery request by sending a POST request to /api/system/verification-codes and providing a username in the request body. If an app is using an SMS text message challenge where a six-digit code is sent to a user's phone, but the input field is not limited, the application can be broken into in just a few minutes. An attacker simply needs to send every possible six-digit combination into the application until they hit the correct one.

In that scenario, on the surface, it looks like having two-factor authentication will keep an application safe. But because the user input isn't rate limited, the authentication is broken and vulnerable.

In another example, an application might use encoded user objects as authentication cookies. But if an attacker with low-level user access decodes that cookie using Base64, they could discover how the cookie defines sessions and users to the application. For example, they may see the following JSON once decoded:

{
"username" : "ShadyGuy",
"role" : "user"
{

At that point, the malicious user could change their username, role, or both. They could become another user with a higher privilege level by changing a couple of values:

{
"username" : "GoodGuy",
"role" : "admin"
{

At that point, if the attacker recodes the information and sets it as the cookie value, they essentially become the new user with a higher permission level. Unless methods are in place to prevent a change like that, there is a good chance the application will accept the transformation.

Eliminating Broken or Misconfigured Authentication

If authentication fails, there is a good chance that security across the board will be compromised. But following a few important guidelines while coding applications can help to keep everything secure.

First off, be sure to include authentication checks everywhere that allow users to access program functionality. If the authentication check doesn't exist at all, then the battle is lost from the start.

In terms of best practices, one good thing to keep in mind is to avoid exposing session IDs in the URL that is accessible to users. In the second example above regarding broken authentication, keeping an attacker from trying to decode the session cookie is a lot easier if it's never exposed to them.

It's also a good idea to implement multifactor authentication. This can be done securely using hardware tokens that algorithmically generate passwords on tight schedules. If you aren't able to provide your users with devices like that, SMS text messages can also work. But you need to make sure that user requests are limited to something reasonable like three or four tries in a 30 second period, and that the codes expire all together after only a few minutes. Using an alphanumeric code can also improve security by adding letters and numbers to potential passwords.

Finally, if possible, avoid depending on user names or predictable sequential values as session IDs. Instead, use a secure server-side session manager that generates a random session ID each time.

Implementing secure authentication methods is a little more tricky than combatting the average vulnerability. But because authorization is so important to every application, program, and API, it's worth taking extra time to make sure that you get it right.

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.

One of the best things about working in a tech startup is all the interesting, clever people you get to meet and collaborate with along the way. Growing a company from a cool idea into a serious market contender requires the assembly of your very own team of Avengers (or, Justice League, depending on your allegiance).

With that in mind, we'd like to shine the spotlight on one of our experts, Oscar Quintas. He's part of our Product Content team, working as a Senior Security Researcher. He's also our resident sorcerer on all things Infrastructure as Code (IaC). He is the force behind our 178 (and counting!) IaC platform challenges, and our go-to for all the burning questions we have regarding this fresh, piping hot topic.

We think he's pretty special, so we'd like you to get to know him a little better. Here he will share his insights on the piping hot topic of Infrastructure as Code security, his role, and what organizations can do to better prepare their cloud infrastructure and engineers:

Q:Tell us about your role at Secure Code Warrior. What does a typical day look like for you?

A: I am part of the Product Content team working as a Senior Security Researcher. A typical day involves reviewing challenges code in different languages (Python, Java, Golang, and many others!) to ensure that code quality standards are met, and security best practices are implemented. I also develop new IaC content.

Q: You have been the genius behind all of our Infrastructure as Code platform challenges. What is your process?

A: I would say it is a combination of research, and working hard to deliver content that provides high relevance and engagement to multiple skill levels. I usually start by looking at the most common problems users are facing when deploying infrastructure, and with that information, I develop useful challenges to show the security best practices for each case.

I always try to offer a good learning experience for our warriors, and ensure it is a job-relevant and useful exercise with an ongoing benefit.

Q: IaC security is a really popular topic at the moment. What are the main issues facing companies in terms of their cloud security practices?
A: Infrastructure as Code is all about managing your infrastructure resources using code. With just a few lines of that code, you can deploy hundreds of cloud resources (network, firewall rules, virtual machines, containers, etc.) that can contain security bugs if not properly configured. So, the same principles applied for secure application deployment can apply to IaC, and these risks -- and their fixes -- must be understood by every team involved in the SDLC.

This awareness and action begins with proper training in IaC security, and prioritizing the secure coding skills of your cloud engineers. They can be a powerful layer of defense, and this is especially important when they are building the infrastructure that hosts applications.

Q: There is a lot of industry interest around Kubernetes, and it seems to be used widely. However, our platform data reflects Terraform as an overwhelmingly popular language, with high engagement. Do you have any insights to share on why it is gaining such traction?
A: Terraform is the de facto language for IaC as it allows us to deploy infrastructure resources in multi-cloud environments (e.g. AWS, GCP, Azure) using a simple syntax. It allows you to define your infrastructure using code and it transparently interacts with cloud APIs to manage the deployment of the resources.

This language is incredibly versatile, and as it can be added to source control repositories, DevOps / DevSecOps principles can also be applied to the infrastructure deployment. However, this will also introduce new threats that must be addressed, so comprehensive training in secure coding with Terraform is a must.

Q:Youre an IaC security expert. What is the best part of your job?
A: IaC is still in its early days so there are a lot of new things being released frequently. It is a bit challenging to keep up to date with these new technologies, but it is rewarding at the same time. I really like to learn new things and test security best practices for new services.

Take your IaC security to the next level.

If you want your cloud developers to hone their security skills around Infrastructure as Code, challenge yourself with our IaC Top 8! Read each chapter for the full run-down of eight common IaC security bugs, including interactive challenges to test their new knowledge.

Let us know your score, and make Oscar proud!