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!

Threats to cybersecurity these days are ubiquitous and relentless. It's gotten so bad that trying to keep up with them after programs are deployed has become almost impossible. However, in this age of DevSecOps, continuous delivery, and more data paydirt than ever before, shrewd organizations are helping their developers upskill into security-aware superstars that assist in eliminating common vulnerabilities before they ever make it to production. We've addressed web vulnerabilities, plus our own Top 8 Infrastructure as Code bugs, and now it's time to get acquainted with the next big software security challenge. Are you ready?

This next series of blogs will focus on some of the worst security bugs 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.

A perfect example of why it's essential to use code to enforce security can be found in an examination of the broken object level authorization vulnerability. This happens when programmers fail to explicitly define which users are able to view objects and data, or provide any form of verification to view, change, or make other requests to manipulate or access objects, allowing them to modify and access objects and data through API endpoints. An API endpoint is a touchpoint, often an URL, that is utilized for communication between the API itself and another system. The ability for connectivity between apps has elevated some of the world's most beloved software, but it comes at the risk of exposing multiple endpoints if they are not air-tight.

It can also occur when coders forget or inherit properties from parent classes, without realizing that doing so also leaves out a critical verification process within their code. In general, object level authorization checks should be included for every function that accesses a data source using an input from the user.

Think you're already familiar with these, and can find, fix and eliminate an access control bug right now? Play the gamified challenge:

How did you fare? If you want to work on your score, keep reading!

What are some examples of broken object level authorization vulnerabilities?

Object level access control vulnerabilities allow attackers to take actions that they should not be allowed to do. This might be an action that should be reserved for administrators, like accessing or viewing sensitive data, or destroying records. In a highly secure environment, it might even mean preventing anyone from viewing records at all unless they are specifically authorized to do so.
You should keep all possible actions in mind when defining object level authorization. For example, in Java Spring API, an endpoint with a potential issue might look like this:

public boolean deleteOrder(Long id) {
       Order order = orderRepository.getOne(id);
       if (order == null) {
           log.info("No found order");
           return false;
       }
       User user = order.getUser();
       orderRepository.delete(order);
       log.info("Delete order for user {}", user.getId());
       return true;

The API endpoint deletes orders by ID, but does not verify if this order has been made by the current logged-in user. This presents an opportunity for an attacker to exploit this loophole and delete the orders of other users.

For safe access restrictions to be properly implemented, the code would look more like this:

public boolean deleteOrder(Long id) {
       User user = userService.getUserByContext();
       boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));
       if (orderExist) {
           orderRepository.deleteById(id);
           log.info("Delete order for user {}", user.getId());
           return true;
       } else {
           log.info("No found order");
           return false;

Eliminating broken object level authorization vulnerabilities

The access control code does not need to be overly complicated. In the case of our Java Spring API environment example, it can be fixed by tightly defining who can access objects.

First, a verification process must be implemented in order to identify who is making the request:

User user = userService.getUserByContext();

Next, we must ensure the object id exists and belongs to the user making the request:

boolean orderExist = getUserOrders().stream()
               .anyMatch(order -> (order.getId() == id));

And finally, we proceed to delete the object:

orderRepository.deleteById(id);

Keep in mind that you need to ensure that the authorization method in your code aligns with your organization's user policies and data access controls. As a way to ensure that your code is fully secure, you should carry out checks to verify that users with different permission levels have access to the data they need to perform their jobs, but are prevented from viewing or changing anything that should be restricted to them. Doing so might uncover missing object control vulnerabilities that have accidentally been overlooked.

The main takeaways from these examples are to first define every action that a user could take with an object, and then add strong access controls directly to the code. And finally, never trust the inherited parent properties to do that job or to delegate that authority elsewhere. Instead, define user permissions and actions in the code explicitly for every object type that you need to protect.

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 Japanese onomatopoeia, the phrase "doki-doki" ("""") represents the sound of a heavily beating heart... which is exactly what members of the security team might experience if their Docker server is infected with Doki, a new vulnerability that provides a back door for malicious code injection, and much more. A fitting name, to say the least.

As we adopt an increasing dependency on cloud infrastructure, the need for precision and scalable effectiveness of security best practices is vital, and it needs to extend far beyond the bare minimum for secure application deployment, with custom measures for container security made known and deployed throughout the SDLC.

Cyberattacks are only getting more frequent, and threats affecting Linux-based infrastructure are becoming more common, with the end goal being an opportunity to crack open a loot chest of sensitive data stored in the cloud. Doki aims to do just that, and its use of multiple technologies to remain undetected, powerful, and effective is unlike anything previously seen in the realm of Docker-based security issues.

What is Doki, and how does it work?

As is a common theme in many compromised applications, security misconfiguration plays an unacceptably large role in how software was breached. For Docker specifically, misconfigured Docker Engine API has proven fruitful for attackers. The Ngrok Botnet cryptomining bot has been sniffing around for insecure Docker servers since 2018, spinning up its own containers and executing malware on the victim's infrastructure.

Doki is a more cunning, malicious version of this malware, made successful through the same botnet exposing the same attack vector: API misconfiguration, which should have been addressed well before any code deployment or public visibility of the server. Doki utilizes the blockchain of everyone's favorite satirical cryptocurrency, Dogecoin, to act as a virtually undetectable back door. As it stands, it has slithered around without much of a trace since January.

The malware essentially abuses a blockchain wallet in order to generate command-and-control (C2) domain names, which is not new in and of itself, but Doki provides a continuous capability for remote code execution on an infected server, making way for a range of damaging malware-based attacks, like ransomware and DDoS. It is relentless, like a "Doge with a bone", if you will. The good folks at Intezer have a full write-up on the entire threat and its sprawling payload.

Spotting a Doki pathway in code.

The fact that Doki is a backdoor operating on a decentralized blockchain network, employing elusive and rapid container escape techniques to cover tracks, access more areas of the host and continue spreading the infection, makes it somewhat of a nightmare for developers and security teams alike.

Still, Doki cannot infect a Docker server that has secure API ports. Misconfiguring those during production is a mistake with far-reaching consequences, but effective training on both security awareness and practical secure coding skills for cloud developers is a somewhat "simple" fix, in the face of such a complex and hard-hitting piece of malware.

Let's take a look at this example of an insecure Docker API, one where Doki could find a way in and start spreading:

dockerd -H tcp://0.0.0.0:2375

Can you spot the misconfigurations? The secured version looks like this:

dockerd -H tcp://0.0.0.0:2376 --tlsverify --tlscacert=/etc/ssl/certs/ca.pem --tlscert=/etc/ssl/certs/server-cert.pem --tlskey=/etc/ssl/private/server-key.pem

In the insecure example, the Docker Engine API is listening on port TCP 2375, and it will accept any connection request, so it is available to anyone reaching the Docker server.

In the secure example, the Docker Engine API has been configured to use TLS certificate validation, and it will only accept connections from clients providing a certificate trusted by your CA.

We have an all-new set of gamified challenges to help developers identify and fix the root cause of a Doki infection, and you can play one here:

Secure cloud infrastructure is a team sport.

Cloud misconfigurations cost organizations a mind-blowing $5 trillion over 2018 and 2019, representing billions of exposed records and irreversible reputation damage. For an attack vector that is largely avoidable, this is a rather alarming statistic. And to think that measures like monitoring for and fixing exposed ports (ideally before deployment), checking for any unknown containers, and keeping an eye on any excessive server load could stop the snowballing damage of something like Doki, well, it's a small price to pay for peace of mind.

Company-wide security awareness is critical, and for every single person involved in the SDLC, operating with security best practices is not negotiable. The best organizations are committed to a solid DevSecOps process, where responsibility for security is shared, and developers and AppSec professionals alike have the knowledge and tools to stop common vulnerabilities from making their way into software, and in vital infrastructure.
Want to get started as a security-aware, supercharged cloud engineer? Start testing your skills now.

We're barely half-way through 2020, and yet we're already on track to set a grim data breach record, seeing a 273% increase in stolen data as compared to the first half of 2019. These days, it's more accurate to ask how much data hasn't been stolen yet. With world events like the COVID-19 pandemic, these attacks have only increased in frequency and potency, with increasingly vulnerable targets.

This is something we have all known for a while: security is no longer optional, and our focus must be a pre-emptive strike. For that to be effective, everyone in the SDLC must be security-aware, especially developers. This is the "DevSec" part of DevSecOps, an ideal software development methodology for the climate, but many organizations are not fully prepared to execute this effectively.

With your organization in mind, think about these questions in the context of your role. How would it fare when put to the DevSec test?

DevSec Self-Assessment: Is your SDLC garden ready to bloom security-aware engineers?

1. Is security front-of-mind in the internal development process?
   A range of cybersecurity risk factors might be keeping the average CISO up at night, but the concerning reality is while many companies are making security more of a priority, their internal approach may not be robust enough to mitigate potential disaster (or, at least, massive headaches for the AppSec team and delayed shipment of software).
   DevSecOps might be the current state of security nirvana, but few companies are working with this methodology. If you're still in Agile -- or even Waterfall -- then security is often still considered the domain of specialists that are far removed from the process and activated late in the SDLC, popping up to ruin a developer's day with hotfixes for their code. In an environment like this, it is going to be challenging to drive a DevSec culture: developers love and prioritize feature-building, and simply won't have had enough hands-on experience with security to see it as a desirable upskill pathway. In fact, their touchpoints with it may be ones of frustration and negativity. This must be remedied quickly to instill a front-of-mind approach for everyone involved in the software development process.
   ‍
2. Is your organization still playing catch-up when it comes to threat modeling?
   It's a sobering statistic that 60% of SMBs go out of business within six months of a successful cyberattack, and much like other disasters, the impact is far greater without adequate planning.
   Threat modeling is a crucial element of security best practices, allowing AppSec professionals to assess the full scope of the attack surface and structure appropriate defenses, countermeasures, and planning. In companies who have fully embraced DevSecOps, security is enabled early in the CI/CD pipeline, in such a way as to not slow down production as much as it may have in the past. Security, secure coding, and continuous delivery are all part of the process, and development teams are given the resources and exposure required to be major components of the engine spitting out air-tight code.
   ‍
3. Do development managers prioritize security best practices?
   Whether they like it or not, development managers are role models for their team. And it's not just for the culture and vibe stuff, like wearing flip-flops to the office or how they "manage upwards". Their working priorities will inevitably be absorbed by their team members, and if security is not part of the key objectives, or planned for in terms of training and support, then the engineers underneath them will be missing out, and the business will be more at risk than it should be.
   ‍
4. Are developers given a reason to care about security?
   In my experience, the fastest way to get someone offside is to tell them they have to do something that is foreign to their current approach, without telling them why.
   
   Being told to "change" implies that the previous approach was wrong, when in many cases, it's simply an enhancement that will hopefully make things easier and more efficient later. To truly embrace the DevSec movement, developers need to be given a reason to care about security in the first place - after all, in most organizations, it is still very much "someone else's problem" (i.e. the AppSec wizards locked away in another room, far, far, away).
   
   DevSecOps simply doesn't work if security is not a shared responsibility. Developers need the right tools, support and training to do their part... and this requires time to roll out and perfect as part of an overall security program. The worst approach is the one that overwhelms and alienates, which can be the case when developers have too many competing priorities and no help to manage them without sending themselves crazy. This is a cultural shift, and it's not overnight.
   ‍
5. Are you relying on a handful of magical security unicorns to take on the task of many?
   Security professionals are in very short supply, and we need far more than are currently available. That is a given, but there is an increasing number of developers moving to more security-focused roles. Typically, they might be under titles like "security engineer" or "DevOps engineer" (slowly, we'll see this title morph into DevSecOps engineer, with any luck!). A gun DevOps engineer is able to develop features for virtually any application, while deploying using a true CI/CD pipeline. They do everything end-to-end, and usually come with a healthy dose of security awareness. In that sense, they are kind of magical, and rare as a result.
   
   However, some companies make the mistake of hiring these specialist engineers, plopping them into a team and expecting they will be across all the security problems, at every stage of the development process, and this alone is the cure-all. Overburden your DevSecOps magicians, and you'll end up where you started - shipping insecure code without the checks, balances, and security precision they were hired to perform in the first place. It is of utmost importance that the development team in general is upskilled, and nurtured in a positive security environment so that they are equipped to share the load in a meaningful way.

Find the change you want to see in your organization.

If you implement robust training as part of your security program, you will uncover some hidden gems in your development cohort. These are the people who, despite any negative experiences they might have had in their day-to-day work, have something of a passion for secure coding and security best practices. These folks are prime candidates for security champions within the team; a point of contact between security and engineering who sets a great example for others, keeps awareness high, and helps with engagement initiatives. Their interpersonal skills are also very important in spreading security joy far and wide, and advocating for the developers'needs to management and the security team.

The "what's in it for me?" conversation is a positive step forward.

Even the noblest of humans need something of a "carrot" to dip their toe into unfamiliar territory, or an activity that may not have the most pleasant of learning curves.
Making the leap from "dev" to "DevSec" is an awesome boost for a developer's career. Security-aware developers have worked hard to understand security, take responsibility for it in the areas they can control, and operate with the understanding that the only quality code is secure code. Generally, developers want to improve, tackle new problems, and create enviable features that help them stand out among their peers. Give them a pathway to reach a higher level of software development, and it's a win-win situation.

It's never too late to build your DevSec dream team.

If you manage developers, lead an AppSec awareness team, or you're one of the many minds hard at work devising security program strategies, now is the time to go one better than "shifting" left. With the right training, tools, and environment, you can create a security incubator for developers that will pay great dividends for all parties. If this checklist has highlighted some areas for improvement, then you have a great opportunity to prepare your organization for a DevSec-led engineering department that can reduce risk from the very start of the SDLC.

There is something of an inconvenient truth out there, one that tends to be glossed over by governments, big corporations, and even some industry leaders: as a society, we are in a constant battle against cyber threats, and we are currently on the losing side. How do we know this? These statistics tell a sobering story:

• Cybercrime is estimated to have a global cost of USD $6 trillion by 2021
• A cyberattack occurs every 39 seconds
• 24% of data breaches are caused by human error
• An alarming 77% of organizations do not have a cybersecurity incident response plan that scales across the enterprise, and is applied consistently between departments.

When it comes to cybersecurity specialists, we are critically understaffed; the skills gap is unlikely to be filled, and there is no secret AppSec army coming to bail us out. We've known this for years, and we've got to change our approach. In our case, the best attack is a great defense, and we can strike first with a good plan.

This all sounds a bit depressing, but it's not as bad as some may have us believe. We've got an ace up our sleeve, and the cybersecurity climate presents us with a golden opportunity. You need not look further than your internal development teams for the personnel that will come to rescue the organization, but your security program must support their trajectory to becoming security-aware engineers that are ready to share the responsibility of coding securely.

Any old training won't do the job - we've certainly said that enough - but even the right training that engages, builds contextual knowledge and helps developers love security could be far more effective, if only it was more curated for the needs of the business, the threats they face, and the compliance requirements that help businesses keep all of our data safe.

And that's where our newest features, Courses, comes into play. By the way, if you got the reference in the title, you're officially old (or just appreciate a classic).

Organization-specific learning: build defense, bolster developer skills

We have all kinds of opinions on why some types of developer training are better than others (i.e. don't bore them to death with hours of dry, generic video sermons, and then expect a passion for secure coding to bloom). But even with competitive learning that is designed to appeal to a developer mindset, the content may still be a little broader than is needed for particular requirements within an organization.

A curated course containing the exact modules in which your developers would need to show proficiency will have a potent impact, and allow them to hit the ground running when it comes to security best practices in their day-to-day work. Tailor programs to suit frontend teams, cloud engineers, and more, with the ability to drill down into the vulnerabilities that matter most, in the languages and frameworks that are relevant to them. Developers will grow their skills with continual context, touchpoints and experience, while the business will benefit from precision awareness on the issues that pose the most risk.

Customize a course for compliance

Tighter cybersecurity-related regulations are being imposed all over the world, and software security compliance is a great foundation on which to build a positive, effective security culture. It shouldn't be boring, and a good security program ignites a sense of pride and responsibility in developers, as opposed to a groan and facepalm.

As a starting point, it is a very good idea to get everyone up to speed with the OWASP Top 10, but to really reach new heights in industry-relevant compliance, you can design a custom course around the requirements of specific regulations. For example, a financial organization could tailor a course to suit the compliance requirements of their software, in accordance with the PCI-DSS guidelines that govern payment and card processing applications. The stakes are high when you're in charge of processing and storing sensitive information like credit card numbers, and getting ultra-specific with developer learning cuts through the noise, delivers the right education at the right time, and makes team aptitude far easier to monitor.  

This is how General Electric (GE) is using Courses within their teams:

"Courses are a great solution for our engineers. With the new feature - which bundles the learning pathway, videos and checkpoints into a customizable module - we have the ability to shape content based on what we need at any given moment. The compliance capabilities and flexibility provide an even better opportunity to ensure a more streamlined and flexible process.  This capability has helped General Electric to tailor relevant training to each engineer faster and easier than ever."

And remember, it might be curated compliance training, but it's still delivered as the bite-sized, contextual, engaging learning experience that is far more appealing to developers.

A positive security culture built on respect and relevance

Education is a lifelong process, but in the frantic world of DevSecOps, there are a lot of plates to spin. The time set aside for training should be used wisely, with a viable learning path that continues to engage and add value.

By curating a custom course that is hyper-relevant, you are respecting the developer's time and workflow, while at the same time working towards a measurable reduction of vulnerabilities and cybersecurity risks for the business.

The relationship between AppSec specialists and engineers is traditionally fraught with misunderstandings and strain, but structured learning with Courses can enable both parties to get on the same page with security best practices. Developers will certainly appreciate some solutions-focused enablement from the AppSec team, which minimizes the load on them and assists them in crafting a higher standard of code.

Erase weaknesses, scale enterprise-level security hygiene

We're all human, and unfortunately, we make mistakes. Those mistakes can be extremely costly in the digital world, yet they are astoundingly common. Symantec's 2019 Internet Security Threat Report confirmed that more than 70 million records were stolen as a result of misconfigured S3 buckets. Security misconfigurations are a leading cause of data breaches, with human error accounting for around a quarter of them.

These issues happen for a number of reasons, but a lack of security awareness and training is a huge driver for small windows of opportunity being left open for attackers to exploit. For scalable security hygiene that makes an impact, you must make it count with a course custom-made for your business. Show no mercy to your foes, and shut down every opportunity for them to cause the biggest headache you're ever likely to encounter.

We're already seeing an amazing impact with our clients, including this leading cloud-based accounting SaaS provider:

"Courses'tailored learning pathway has been a game-changer. The specificity around the programming languages and the vulnerabilities provide more control and flexibility to create the right learning experience for each developer based on individual and company needs. Using Courses in conjunction with Secure Code Warrior's wider secure coding platform has transformed our developers'engagement, in that they are now more interested in enhancing their secure coding skills to write better and more secure code."

Get DevSec-ready. Find out more about Secure Code Warriors all-new Courses feature here.

The Software Development Lifecycle (SDLC) seems innocuous enough; it's a process, and us software people all come together to make the magic happen and ship off all those digital goodies society cannot live without.

Except... if you've ever been part of a software development project, you'll know it's usually a gauntlet, with many quests to conquer and dragons to slay. It's fun for a while, but burnout is real, and the demand for software has us all working at the speed of light at the best of times, especially the development team.

Now imagine they're thrown another must-do task... responsibility for security in the project elements they touch. This, at worst, may cause the house of cards to come crashing down for some individuals, but the more realistic scenario is that it's simply not made a priority, and the issues deemed more pressing to get over the line take precedence. And when most developers aren't trained to code securely (especially if their managers are not prioritizing security, either), it's little wonder we see frequent data breaches, flawed app releases, and some serious churn among security professionals reaching breaking point under an avalanche of buggy code.

Developers need an AppSec advocate.

When taking in the scenario above, you can understand why security is put in the "too hard" basket during the coding process, and left to the security team to work out. Too many competing deadlines, not enough training, and no real reason to care about security with everything else going on. However, there is simply too much demand for code for this status quo to continue. And that's where super-elite developers can stand out from their peers, learn new skills, and most importantly, build safer code.

However, it's important to remember that it's not all on the shoulders of developers to manage software security - that's still the domain of the AppSec team (who, when working with security-aware developers, will have more breathing space instead of fixing common bugs on repeat). A functioning DevSecOps process requires every member of the team to have the support and tools they need to share the responsibility for security, and the right kind of training is paramount. Balancing the right suite of tools and training requires the insight of AppSec professionals willing to work closely with devs to inspire them and drive positive change.

Disruptive training is more annoying than it is effective, and anything repellent to developers isn't going to work. An IDE or issue tracker-integrated solution focused on bite-sized knowledge is one alternative, and it gets the right information in front of them, at the very moment it is needed.

Here's how it works in action:

Just-in-Time, not "just in case".

Contextual, hands-on learning is by far the most effective way to train, with bite-sized chunks delivered right when they make the most sense. This is sometimes referred to as "Just in Time" (JiT) training, and it's very powerful for developers learning secure coding.

With origins in Toyota's lean manufacturing principles, JiT training is designed to activate on a need-to-know basis, in context, when it matters most. Has a developer just written something that looks to have improper permissions? What if a small back door was opened that allowed an attacker to remotely execute code? It will be far more memorable if developers can access knowledge right as they need it, rather than trawling back through documentation in Confluence, or Googling something that was touched on in training.

Just-in-Time is the antithesis of "just in case" learning; while the latter is the more common way of imparting knowledge, it's simply not efficient. We must make it easier for developers to engage with secure coding best practices, and see the benefit in upskilling for their career while maintaining focus on the key objectives they are working on right now.

Stop making developers chase the training.

We already know there is too much going on in a workday, so what incentive do developers have to schlep off to a classroom, or context-switch to go through five steps to access static theory-based training?

The general consensus is that whatever most organizations are doing is not terribly effective if the amount of vulnerabilities causing data breaches is anything to go by. The 2020 Data Breach Investigations Report from Verizon specified that 43% of data breaches could be attributed to web vulnerabilities. Developers are not receiving effective training; not in tertiary education, nor as part of workplace upskilling measures. If they were, common vulnerabilities like SQL injection and old-school path traversal would not be exploited for significant data paydirt, and the cybersecurity skills shortage wouldn't be out of control.

So, knowing this is the current climate in which developers receive training and get acquainted with security, why are we surprised at the poor outcome? It might just have an effect -- a positive one -- for both the developer and organization to ensure a smoother, more integrated and less jarring training experience, where it is accessible in the spaces they actually work in, like Jira, GitHub, and in the IDE. The industry simply needs to move forward and make security awareness much easier, in an environment where it's no longer a luxury.

Ready to secure the development workflow?

Security-aware developers are revered for their skills, and the protection they can offer organizations right from the code-building stage. Security is no longer optional, especially with GDPR fines, PCI-DSS compliance regulations, NIST governance... and the possibility of being sued in a big old multi-million-dollar class action, a'la Equifax.

An integrated approach might be the catalyst to start winning over developers with less disruptive learning, and create some pathways for more in-depth courses, training up security champions, and generally inspiring that shared responsibility we need to keep the world's data safe and sound.

Download integration tools for Jira and GitHub now, and let us know what you think.

Think about the last time you were at work, perhaps in a software project team working to an impossible deadline. And then, your manager comes along and says there is some mandatory security training to do, and that it needs to be shoehorned into your workday on top of everything else.

They know it, and you know it. It's a huge PITA, but for compliance reasons, you'll be playing some boring training videos in the background while you keep coding, tuning in and out of both tasks and giving your full attention to neither. This is a common scenario; it's highly disruptive, and it wastes everyone's time. Most security training is too generic, and it's easy to ignore something that bounces in and out of a workday with no real value.

As a company, our goal is to bring a better, more effective type of security training to you, and this is born from knowing exactly what it's like to be disengaged from what the AppSec team tells you is important, when each of your priorities is misaligned. What is interesting, though, is that we started to think about what we could do to reduce the barrier to getting training when you need it - even with our full platform, there are a few steps involved that take you away from your work, at moments where you still need a helpful push but can't dedicate a block of concentration to a training session.

We looked at how micro-learning could be implemented into your workflow, in the IDE or issue tracker, in a more seamless way. And this is what we came up with:

This is based on Just-in-Time (JiT) principles, wherein you're served the right knowledge, at the right time for it to be immediately effective and useful. It's the opposite of the just in case approach to learning, which is often a state of information overload that takes away precious time and headspace for building features.

Quality code is secure code, and if you need a non-invasive security sidekick to collaborate with occasionally, then it might be worth your while to take it for a test drive.

Eliminate the barriers, and bring the training to you.

Cybersecurity might be an interest for some, but not everyone. And no-one should expect developers to become security experts - that still remains the job of specialist AppSec teams. However, security-aware developers are revered for their skills, and the protection they can offer organizations right from the code-building stage. It's a position in high demand, and you can build the foundations over time with contextual micro-learning.

Now, if you're thinking about integrated training as more like Clippy (may he rest in peace), then it's important to note that in the case of Secure Code Warrior's integrations, they're built by developers for developers, so the irritation factor has been considered and obliterated.

Let's check it out in action:

Secure Code Warrior for Github inspects code for Common Weakness Enumeration (CWE) or OWASP references in the labels, issue title, and body of issues to display contextual just-in-time training. The way it works is if a vulnerability reference is found, a comment will be posted on the issue to assist in swift resolution and prevention of recurring vulnerabilities. It integrates with the issue without disruption of your process, or making you jump through hoops for a solution.

And if you use Jira, the process is similar:

Now, for the incumbent security-aware superstars, it's important to remember that it's not all on you to make magic happen. You're going to need support, training, and a reason to take security seriously and get it into your own workflow. Luckily, this is all part of a functioning DevSecOps process, and lots of organizations are already taking note. Why not get a head start?

Download them now, and let us know what you think.