Most organizations are still struggling to emphasize security as a critical element of the software development lifecycle (SDLC) with few being able to conquer the robust DevSecOps approach.  For many, prioritizing features and release deadlines is still taking precedence over security. This comes with repercussions, including the increased risk of an expensive data breach and reduced productivity as teams sift through security tickets and rework. 

Because developers are the first line of defense when it comes to eliminating risk from software vulnerabilities, it is important for organizations to think about increasing the maturity of their development teams. But this raises a number of questions.

How does an organization assess the security maturity of its development teams? How can setting up a security maturity roadmap not seem like an impossible task? How can you keep your developers engaged and motivated to improve their security maturity? 

We have used insights from the Secure Code Warrior State of Developer-Driven Security Survey to understand the answers to these questions and made use of our world-class Customer Service teams to discover what other organizations are doing to find the answers. ‍

How can you increase the security maturity of development teams?

No two organizations are the same when it comes to improving security maturity, with many variables to consider that can impact a company’s success in its efforts to shift left. There are many benefits to those who do - including faster creation and release of code with fewer or no vulnerabilities, which in turn reduces expensive rework, and ultimately reduces risk. 

Those organizations that make progress have a defined plan with management support, and a cohesive approach to continually improve security maturity over time that covers (amongst other things): 

• Defining a security maturity baseline
• Assessing teams’ security maturity
• Identifying key security weaknesses
• Building a positive security culture

Check out our new whitepaper The importance of security maturity in development teams to take an in-depth look at:

• What is security maturity in development teams, and why is it important?
• What are the different stages and characteristics of security maturity for development teams?
• What is needed to build security maturity in development teams?

The importance of developer security skills is highlighted in the 2022 Gartner Cool Vendors in Software Engineering. Read the full report here.

Secure Code Warrior has been recognized as one of four ‘Cool Vendors in Software Engineering: Enhancing Developer Productivity’, by Gartner. According to Gartner, the “definition of a Cool Vendor is a small company offering a technology or service that is innovative, impactful or intriguing." The three elements of a Cool Vendor include:

Innovative — Enables users to do things they could not do before.

Impactful — Has or will have a business impact, not just technology for its own sake.

Intriguing — Has caught Gartner’s interest during the past six months.

As outlined in the report, “Software engineers struggle to navigate complex code environments and to improve security of the systems they build while remaining productive. These Cool Vendors offer innovative solutions that help software engineering leaders boost developer productivity and mitigate security risks.”

As the only company listed that focuses on developer-driven security, this recognition is a testament to our strategy to enable developers with the right security skills and contextual tools so they can rapidly learn, build and apply their skills to deliver secure code at speed, for improved software security.

While the virtues of shifting left have been extolled for some time now, many organizations still struggle to ensure that security is considered at the start of the software development lifecycle. Our recent ‘State of developer-driven security survey’ highlighted that a lack of time is the biggest hurdle to be overcome when adopting secure coding practices, which is also reflected in this recent Gartner report. With a significant shortage of skilled engineers, combined with vast and complex code repo’s and over half of the runtime stack consisting of open-source software, developers barely have enough time to maintain existing code - never mind ensure its security.

At Secure Code Warrior, our solutions are driven by the need to improve productivity at the same time as ensuring software security. Despite citing a lack of time to adopt secure coding practices in the aforementioned survey, 76% of respondents agreed that good training in secure coding would actually improve productivity with fewer security tickets and rework to manage. When armed with the right security skills and tools, developer teams can easily mitigate risk and consistently ship secure, quality code at speed, with innovative features and functionality. 

So thank you Gartner for the recognition - not just for Secure Code Warrior but for highlighting the important role that security-skilled developers can play in cybersecurity.
‍

Access the Gartner Cool Vendors in Software Engineering: Enhancing Developer Productivity report now. 

‍

A version of this article appeared in Security Magazine. It has been updated and syndicated here.

‍

For security professionals, there is something special about December 13. Is it the day we finally eradicated SQL injection, forever? Of course not. Perhaps it’s “International Security Worker Appreciation Day”? Also no. It is the day that FireEye and Mandiant released their shocking report about a previously unknown global intrusion campaign that would become known as SolarWinds. The report detailed an ongoing and almost unbelievable attack where malicious code was hidden deep inside the software updates of SolarWind’s popular Orion management software.

Over 18,000 SolarWinds customers had already downloaded the corrupted update. Many of them did it automatically, just like they did for hundreds of other software updates within their organizations and networks. The attackers were highly selective in what they chose to attack once given access through the SolarWinds breach. Many major corporations, as well as government agencies, had their data stolen and their networks compromised. It was one of the largest and likely the most costly breach of all time, especially since in the case of government agencies, the full extent of the damage has never been publicly shared.

And it all happened because people trusted the vendors within their software supply chain without properly verifying or vetting their activities.

The massive shift to supply chain security

Once the alarm was raised, companies, organizations and government agencies were quick to respond. The SolarWinds breach was stopped of course, but the attack also exposed the dangers of an unregulated and unmonitored software supply chain. While the SolarWinds incident was quickly resolved once discovered, the implications regarding how the supply chain was used as an attack vector are still ongoing. If nothing else good came of the attack, it at least put the spotlight on a critical yet overlooked aspect of cybersecurity.

One of the most high-profile responses to the SolarWinds attack was President Biden's Executive Order on Improving the Nation's Cybersecurity. The order is one of the most comprehensive cybersecurity directives ever issued in the United States. It demands better cybersecurity at agencies and for those who do business with the government, advocates advanced protections like zero-trust networking, and stresses the need for software supply chain security.

While the EO is specific to the government, other groups have also started to emphasize the importance of supply chain security to prevent another SolarWinds-style attack. For example, Palo Alto recently released its Unit 42 Cloud Threat Report entitled “Secure the Software Supply Chain to Secure the Cloud.” The report states that no cloud deployment is totally safe without software supply chain security. And the Cloud Native Computing Foundation agrees, releasing a white paper detailing critical software supply chain best practices that must be followed in the wake of SolarWinds.

It’s safe to say that the past couple of years have been transformational for cybersecurity standards, and while not mandatory, it should be a goal for all organizations to follow suit, and scrutinize vendor security practices as though they are part of their own internal security program. Initiatives like CISA's new Strategic Plan provides further evidence that approaching security as a shared responsibility is forming part of a new standard for all software creators, especially those involved in critical infrastructure or the software supply chain.

What can organizations do to improve their software supply chains?

The situation has many vendors rightly asking what they can do in order to protect their own supply chains. What can an organization do to ensure that its vendors care as much about cybersecurity as they do? 

The EO specifically outlines the impact of software developers, and the need for them to have verified security skills and awareness, which is an area that tends to be forgotten in an industry that is tools-obsessed, rather than a focus on people-led defense through key security skills.

It's become apparent that any comprehensive approach to cybersecurity these days must absolutely include a detailed third-party risk assessment, covering the technical security controls in place and an assessment of how partners view governance, risk, and compliance within their own organizations. 

All third-party assessments should include assurances and detailed plans about how those in your software supply chain plan to release secure program updates with verified certificate signatures, and how they will help to manage the identities of all of their software and devices. It should also demonstrate a clear path for cryptographic upgrades and updates for their products.

And now that developers are finally being seen as a critical component of software supply chain security, any assessment should also include a report detailing how they encourage secure coding and continuous improvement within their development community, and ideally, benchmarking of their skills and current training. We know that emphasis on developer upskilling is improving, but 48% of developers have admitted to knowingly shipping vulnerable code.

Factors such as time constraints, and the reality that security simply isn’t a top priority (nor a measure of success) in their world, contribute to an environment where code-level vulnerabilities are not addressed as early as they should be. If we’re to stop them from infecting the software supply chain, every organization needs to commit to a more developer-friendly security program. 

Next steps?

Risk assessments are critical because, if you use software from a vendor that has security problems, you will inherit them into your ecosystem and bear the consequences. However, organizations should also realize that it’s possible that their vendors might actually be more secure, and may even be better at supporting their developer communities. 

You can use a third-party risk assessment as a secondary way of evaluating your own security. If a vendor is handling some aspect of security better than you are internally, you can adopt their methods to improve your own organization.

Finally, the next big step in really improving the software supply chain is to implement secure coding certifications for developers. Having a good plan in place is the first step, but verification that it’s actually being followed and helping to produce secure code is also a necessity. 

Until we reach a point where developer enablement in secure coding is the norm, we’ll always be behind in closing windows of opportunity before threat actors can peer in. However, it's never too late to make a positive impact with the right support. See how your developers can hone relevant, high-impact security skills with the power of agile learning now.

A version of this article appeared in TechRepublic. It has been updated and syndicated here.

‍

It has been an uphill - yet essential - battle to create an environment where the goals of the security team and their developer counterparts are aligned. We’ve got a long way to go, but the obstacles that stand in the way of the synergy needed to open the door to shared responsibility for software security are becoming abundantly clear. Smart companies want to evolve their strategy to avoid those pitfalls, find a productive way forward, and use DevSecOps to its full people-powered potential.

What I wasn’t anticipating, is that the perception of what constitutes the act of secure coding is up for debate. According to brand new research in collaboration with Evans Data, this sentiment was revealed in black and white. The State of Developer-Driven Security 2022 survey delves into the key insights and experiences of 1200 active developers, illuminating their attitudes and challenges in the security realm.

One of the headline findings was that just 14% of developers consider security a priority when coding. While this shows there is enormous room for improvement, it confirms what we knew already: feature-building is king in the developer’s world, and they remain ill-equipped to make security part of their DNA. However, when coupled with data on developer definitions of what secure coding means to them, it is cause for concern.

These perceptions are driven by developer experience in their working day, and it speaks to the environment of many organizations, which is that developers are simply not a focal point in the fight against common vulnerabilities. Their enablement is critical, but in the meantime, we must quickly get on the same page with the scope of “secure coding”, and what we should expect from a security-skilled developer. 

We need to demystify security in the developer’s world.

Cybersecurity is a multi-faceted, unwieldy beast at the best of times, and while secure coding represents just one part of the overall landscape, it is a complex cog in the system that requires specialist attention.

The survey revealed that the concept of working with secure code was quite siloed for the average developer, with their scope often limited to a single category as opposed to a holistic view of the fundamentals and beyond. Developers indicated a reliance on using existing (or pre-approved) code, rather than the practice of writing new code that is free from vulnerabilities. While security awareness regarding third-party components (especially patching, and the Log4Shell debacle is a great example: 30% of instances remain unpatched since December) is very important, as is testing existing code, these alone do not meet a functional level of secure coding ability. 

Code-level vulnerabilities are introduced by developers who have learned poor coding patterns, and a lack of emphasis on writing secure code in their KPIs (coupled with a lackluster security culture) only reinforces this as an acceptable standard. 

Security leaders can go a long way in improving initial awareness and identifying areas of the most pressing knowledge gaps, by first ensuring that the development cohort is shown the complete picture of what secure coding entails. Testing and scanning pre-approved code is one function, but the reduction of vulnerabilities requires hands-on training in good, safe, coding patterns, in the languages and frameworks that are actively in use.

Context is vital in developer upskilling, and they need to be brought on the journey when it comes to the security goals of the business.

Many organizations need to upgrade their security programs.

With an explosion of software-driven tech making way for the rapid growth of cybersecurity incidents in the last decade, we’re all scrambling to keep up with threat actors working around the clock to uncover exploits in valuable systems. 

The DevSecOps methodology is built on the idea that everyone shares responsibility for security - developers included - and it’s a chief consideration from the very beginning of the SDLC. The problem is, especially in large companies, they may be very far away from implementing DevSecOps as a standard. In 2017, a study by the Project Management Institute showed that 51% of organizations were still using Waterfall for their software development. That study is now five years old, but knowing how gradual changes can be in large enterprises, it’s unlikely that there has been a sharp transition to the latest security-oriented methodologies. These legacy processes can create an uphill battle for security professionals trying to cover all bases with a comprehensive strategy to protect against cyber threats, and retrofitting developers and their needs into this landscape is a challenge. 

However, we can’t use this as an excuse. The security pros in the business can utilize developers in an uplifted strategy; they just need to get familiar with their needs and consider them as part of their defensive play. They need comprehensive training, and any responsibility for security needs to be implemented with respect to their tech stack and workflow. 

Secure coding = the “too hard” basket?

The Evans Data research brought to light that a staggering 86% of developers find it challenging to practice secure coding, with 92% of developer managers also conceding that their teams needed more training in security frameworks. Worryingly, 48% of respondents admitted that they knowingly leave vulnerabilities in their code. 

This paints a very concerning picture. It appears that, generally, developers are not getting frequent, adequate training, nor are they getting enough exposure to good security practices and hygiene. Reading between the lines, it reinforces the crux of the issue: it simply is not a priority for developers to consider security in their work. That, and the training they receive does not build their confidence or practical skills, nor does it help them understand the impact of their decision to ship vulnerable code. 

The Colonial Pipeline ransomware attack was one of the most disruptive supply chain security incidents in the past year, sparking fear that half of the gas supply on the United States east coast would be cut off for an indeterminate period. Thankfully, they were back up and running quickly, but not without significant apprehension in the community. It was one of those crucible moments where the general public faced the prospect of a cyber incident seriously affecting an element of the physical world that isn’t necessarily thought of as software-driven, or a risk for a cyberattack. And all of that chaos was made possible by two old, unpatched vulnerabilities, one of which was the insidious, yet widely known, SQL injection. If developers knew what was truly at stake when they chose to ship vulnerable code, they would quickly see there is no scenario where that is an acceptable business risk.

Functional “P-P-T” is not up to the developer.

The famous “golden triangle” of People, Process, and Tools is not achievable without carefully considered strategy, and developers are not in a position to assimilate into a working security process without consideration of their needs and challenges.

It will take a sizeable culture shift to uplift developer-driven security, and it starts with educational pathways that move both engineers and the security team to greater clarity.

A version of this article appeared in DZone. It has been updated and syndicated here.

‍

For what feels like an eternity at this point, we’ve discussed “shifting left” in the SDLC, taking into account security best practices from the start of software development. DevSecOps was a great leap forward, in no small part because of the emphasis on shared responsibility for security, and the power of a security-aware developer to thwart common vulnerabilities as they write code. 

We have also known - again, for eons - that the type of secure code training chosen to engage and upskill developers makes all the difference. Low-effort solutions motivated solely by regulatory compliance do not build up the bright security minds of the future, and most security awareness professionals have worked that out. Dynamic, contextually relevant learning is best, but it’s critical that the nuances within are understood. 

If we’re going to have a fighting chance against threat actors - and they always have a head start on an organization - developers need a holistic training environment, with layered learning that continually builds skills steeped in best practices.

Developer-driven defensive security measures are not an automatic win.

Our ethos revolves around the developer being central to a preventative security strategy, right there at the code level upwards. That’s a given, and security-skilled developers provide the easiest path to thwarting the types of common security bugs that are apparent in poor coding patterns (like Log4Shell, as one recent, devastating example).

However, the defensive techniques that we can engage to upskill developers do vary, even if they can rightly exist in the same training bucket. 

For example, imagine you were told how to bake a cake, using only directions based on what not to do. “Don’t overbake it”, and “don’t forget the eggs” leaves it open for interpretation, and a huge potential for mistakes that will have an end result fit for Nailed It!. The same is true for defensive security education; what not to do is a very limited part of the conversation, and offers no practical advice to truly act with a defensive mindset. You can tell developers, “don’t misconfigure that API”, but with no understanding of what constitutes correct and secure configuration, there is a lot of room for error.

Developers won’t have a positive impact on vulnerability reduction without a foundational understanding of how the vulnerabilities work, why they are dangerous, what patterns cause them, and what design or coding patterns fix them in a context that makes sense in their world. A scaffolded approach allows layers of knowledge to give a full picture of what it means to code securely, defend a codebase, and stand up as a security-aware developer. And yes, part of that layered learning should be dedicated to offense, and understanding the mindset of an attacker; this is critical to hone lateral thinking skills, which are invaluable in threat modeling and defensive strategy. 

Reinforcing poor coding patterns is a pitfall we can’t ignore.

An unfortunate reality with some methods of developer learning is that the “defensive” part - even when the training is structured with offensive techniques - can reinforce bad habits, even if they are technically validating code security. 

Production of high-quality code should be the baseline in all software development, but the definition of “quality” still appears to be up for debate. The reality is that insecure code cannot be viewed as quality code, even if it is otherwise functional and beautiful. The kicker is that secure code isn’t inherently high quality, either. In other words, poor coding patterns can fix a security problem, but in doing so, introduce another one, or potentially break the software entirely. 

Let’s take a look at an example of poor quality code in the form of a fix for broken authentication, as well as the most secure version for best practice:

‍

using System;

using System.Collections.Generic;

using System.Linq;

using System.Threading.Tasks;

using Microsoft.AspNetCore.Authorization;

using Microsoft.AspNetCore.Http;

using Microsoft.AspNetCore.Mvc;

‍

namespace BadFixesAPI.Controllers

{

    [Route("api/[controller]")]

    [ApiController]

    public class AlertsController : ControllerBase

    {

        private DatabaseContext context = new DatabaseContext();

‍

        [HttpGet(Name = "GetAlerts")]

        // Does not ensure that the user is authenticated 

        public IEnumerable<Alert> Get()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, but does not check any roles

        [Authorize()]

        public IEnumerable<Alert> GetBadFix()

        {

            return context.GetAlerts();

        }

‍

        [HttpGet(Name = "GetAlerts")]

        // Ensures that the user is authenticated, AND that they have the "Administrator" role

        [Authorize(Roles = "Administrator")]

        public IEnumerable<Alert> GetGoodFix()

        {

            return context.GetAlerts();

        }

    }

}

‍

In the first snippet, there is no check to verify that the user is authenticated, which is about as unsafe as it gets. The second, while better in terms of it performing an authentication check, fails to investigate assigned roles and whether permissions are high enough for the information requested. The third checks both user authentication and that they are assigned the “Administrator” role. In an era where least privilege access control should be the norm in most instances, it is critical that roles are set up and checked to ensure that information is only accessible on a need-to-know basis. 

The highest priority for developers is to build features, and while security is not intentionally on the back burner, they don’t necessarily have the skills to avoid poor coding patterns that lead to security bugs, and the benchmark of a good engineer rarely includes secure coding prowess. We indirectly encourage those bad habits if the features are awesome enough, and it’s this mindset that has to change. The problem is, the way some learning pathways encourage hands-on code remediation also potentially reinforces code that is secure, but of substandard quality. By applying a binary “yes this is secure / no this is not secure” assessment, rather than looking deeper into whether it is truly the best approach to resolve the bug and maintain the integrity of the software, there are devils in the detail that go unnoticed. 

Without taking developers through the entire process for a complete view of secure coding, this approach perpetuates the same issues it’s trying to solve. Imagine if we all got our licenses based solely on our ability to drive a vehicle to a destination; a pass mark even though we ran red lights, drove through a hedge, and narrowly missed a pedestrian crossing the street to arrive there. We completed the goal, but the journey we took to get there matters most. 

Developers need to be enabled to care more about creating secure software.

The modern developer has to keep a lot of plates spinning, and it’s no surprise they find security training a bore, especially when it’s not implemented with their workday in mind, and takes them away from their deadlines and priorities. It’s also completely unfair to change their KPIs to include an emphasis on secure coding, when they don’t have the skills built up from regular, right-fit learning opportunities and supplementary tooling. However, the importance of secure software development cannot be overstated, and getting developers on-side with this is crucial. 

As a former developer, generally, we want to do a great job, and being seen as a cut above others in terms of quality output is very motivating. Incentivizing developers to engage with continuous security skill-building is a no-brainer, and they should be rewarded for recognizing the importance of code-level security. Security champion programs, bug bounties and hackathons can be great opportunities to build a positive security culture, and those who roll their sleeves up and get involved should get the loot.

A version of this article appeared in the SD Times. It has been updated and syndicated here.

‍

When we talk about progress, typically, digital advancement is at the forefront of the conversation. We want everything better, faster, more convenient, more powerful, and we want to do it for less money, time, and risk. For the most part, these “impossible” objectives are eventually met; it might take several years and multiple versions (and a team of developers who might start a coup if they’re asked to switch gears on feature design one more freaking time), but every day, code is out there changing the world. 

However, with great software expansion comes great responsibility, and the reality is, we’re simply not ready to deal with it from a security perspective. Software development is no longer an island, and when we account for all aspects of software-powered risk - everything from the cloud, embedded systems in appliances and vehicles, our critical infrastructure, not to mention the APIs that connect it all - the attack surface is borderless and out of control. 

We can’t expect a magical time where each line of code is meticulously checked by seasoned security experts - that skills gap is not closing any time soon - but we can, as an industry, adopt a more holistic approach to code-level security.

Let’s explore how we can corral that infinite attack surface with the tools at hand:

Be realistic about the level of business risk (and what you’re willing to accept)

Perfect security is not sustainable, but neither is putting on a blindfold and pretending everything is blue skies. We already know that organizations knowingly ship vulnerable code, and clearly, this is a calculated risk based on time to market with new features and products. 

Security at speed is a challenge, especially in places where DevSecOps isn’t the standard development methodology. However, we only need to look at the recent Log4Shell exploit to discover how relatively small security issues in code have opened up opportunities for a successful attack, and see that the consequences of those calculated risks to shipping lower-quality code could be far greater than projected.

Get comfortable with being an (access) control freak

An alarming number of costly data breaches are caused by poorly configured cloud storage environments, and the potential of sensitive data exposure resulting from access control errors continues to haunt security teams in most organizations. 

In 2019, Fortune 500 company First American Financial Corp. found this out the hard way. An authentication error - one that was relatively straightforward to remediate - led to the exposure of over 800 million records, including bank statements, mortgage contracts, and photo IDs. Their document links required no user identification or login, rendering them accessible to anyone with a web browser. Worse still, they were logged with sequential numbers, meaning a simple change of number in the link exposed a new data record. 

This security issue was internally identified before being exposed in the media, however, failings in categorizing it properly as a high-risk security issue, and failure to report it to senior management for urgent remediation caused a fallout that is still being navigated today.

There is a reason that broken access control now sits at the very top of the OWASP Top 10: it’s as common as dirt, and developers need verified security awareness and practical skills to navigate best practices around authentication and privileges in their own builds, ensuring checks and measures are in place to protect sensitive data exposure. 

The nature of APIs makes them especially relevant and tricky; they are very chatty with other applications by design, and development teams should have visibility across all potential access points. After all, they can’t take into consideration unknown variables and use cases in their quest to provide safer software.

Analyze your security program: how much emphasis is placed on prevention?

It makes sense that a large component of a security program is dedicated to incident response and reaction, but many organizations are missing valuable risk minimization by not utilizing all the resources available to prevent a security incident in the first place.

Sure, there are comprehensive stacks of security tooling that assist in uncovering problematic bugs, but almost 50% of companies admitted to shipping code they knew was vulnerable. Time constraints, the complexity of toolsets, and a lack of trained experts to respond to reporting all contribute to what has essentially been a calculated risk, but the fact that code needs to be secured in the cloud, in applications, in API functionality, embedded systems, libraries, and an ever-broadening landscape of technology, ensures we will always be one step behind with the current approach.

Security bugs are a human-caused problem, and we can’t expect robots to do all the fixing for us. If your development cohort is not being effectively upskilled - not just a yearly seminar, but proper educational building blocks - then you are always at risk of accepting low-quality code as standard, and the security risk that goes with it. 

Have you overestimated the readiness of your developers?

Developers are rarely assessed on their secure coding abilities, and it’s not their priority (nor is it a KPI in a lot of cases). They cannot be the fall guys for poor security practices if they’re not shown a better path or told it is a measurement of their success. 

Too often, though, there is an assumption within organizations that the guidance provided has been effective in preparing the engineering team to mitigate common security risks. Depending on the training and their awareness to apply security best practices, they may not be prepared to be that desirable first line of defense (and stop endless injection flaws clogging up pentest reports). 

The ideal state is that learning pathways of increasing complexity are completed, with the resulting skills verified to ensure it actually works for the developer in the real world. However, this requires a cultural standard where developers are considered from the beginning, and correctly enabled. If we as an industry are going out into the wilderness to defend this vast landscape of code we’ve created ourselves, we’ll need all the help we can get… and there is more right in front of us than we realize.

Secure Code Warrior and Okta launch a new way to secure developer workflows

Developers are expected to deliver quality code faster than ever before but there is no doubt that unrealistic deadlines can lead to poor software quality and vulnerable code. It is hardly surprising that 67% of developers think they ship code with vulnerabilities, in part due to tight deadlines (State of Developer-Driven Security 2022). As threats and breaches continue to increase, security can no longer be an afterthought, instead it needs to be integrated into the entire DevSecOps cycle.

We’re excited to announce the Secure Code Warrior Connector for Okta Workflows, which enables organizations and developers to write secure code from the start of the software development lifecycle. This new collaboration between SCW and Okta, the leading independent provider of identity, creates a security proficiency check that will empower AppSec Managers to be confident that the team is committing secure code to reduce vulnerabilities all without moving developers out of their workflow. Plus, we’ve added single sign-on for Secure Code Warrior and Okta to make it even simpler to leverage this great new solution.

Reduce the risk of introducing vulnerabilities

Development teams have traditionally relied on reactive or slow processes that are later in the development cycle, such as plugins, scanning tools, or code reviews to locate and fix security issues --though these approaches have many benefits, they simply create too much risk for vulnerable code and future rework. Instead, we’re here to help organizations shift security to the left and take a proactive, not reactive, security stance. The new Secure Code Warrior Connector for Okta Workflows integrates security thinking into the entire development cycle by ensuring that each individual developer has achieved the necessary secure coding skills to be granted repo access to commit code. This integration will ensure that developers are learning about the latest security practices through SCW’s highly engaging platform and that some of the burdens of manual code reviews are reduced freeing up engineering hours to ship more functionality without sacrificing quality.

AppSec and engineering leaders leverage SCW’s extensive learning platform to create personalized assessments and paths to make sure the developers are focusing on your top priority secure coding needs and achieving the right expertise to be confident they can check-in code. With the help of the breadth and depth of content, 6500+ interactive coding challenges, 56+ languages:frameworks, and 150+ vulnerability categories, you can be sure that virtually every need can be met for your organization.

Once you’ve created the right learning strategy for your team, the assessment scores, as well as a course’s completion status, can be used to determine whether developers have the right skills to build software with a security-first approach. Thanks to the new integration with Okta, you can now automate permissions for each developer based on their assessment scores to easily scale each individual developer's approval to commit code or identify opportunities to further their skill set.

Thanks to the flexible and interactive learning experience on the SCW platform, developers consistently enjoy themselves while learning and can see a shift in their approach to learning, from a compliance check-box to compelling and worthwhile.

How it works

The Secure Code Warrior Connector for Okta Workflows is easy to build with Okta Workflows no code identity automation and orchestration configuration, using if-then logic. The Connector uses a set of Actions that help you perform workflow tasks without worrying about the underlying complexities of API calls and configuration setup.

A simple design to secure your developer workflow looks like this:

Here is an overview of the full workflow design:

‍

Let’s go through the steps:

1. Configure the assessment ID used to determine a developer’s security proficiency. Also, add GitHub details such as the organization and the repository as a part of the setup.

2. Using the Action called Check Assessment Completion For User, the workflow checks whether a developer has successfully passed a particular assessment.

‍

3. If the desired course/assessment has been completed or a particular score achieved, then use the GitHub Connector to grant access to the repository. If the requirement is not met, a notification can be generated or another Okta workflow can be triggered to take appropriate action.

‍

The above can be designed to run as a one-off, periodic, or continuous check so that it continues to only admit eligible developers into the secure workflow.

Some of the other possible SCW Connector Actions are:

• List Assessment Attempts For User - lists all attempts that a user has for a particular assessment
• Check Course Completion For User - determines if a user has completed a specified course
• List Course Enrollments For User - lists all enrollments that a user has for a particular course ID
• Custom API Action - to execute any API call other than what is possible through the available Actions

Release high-quality secure code faster with confidence

SCW Connector helps reduce the risk of introducing vulnerabilities at the start of the software development lifecycle. Just as code reviews and scanning tools, it performs the role of a quality gate to ensure that developers are writing secure code from the start. As a result, less time is spent on reviewing code and fixing avoidable issues, and the focus shift towards shipping quality code faster. Additionally, the Connector also helps promote a security-first culture by encouraging developers to proactively engage with SCW’s learning platform to maintain their security proficiency. As developers continue to learn and improve their security maturity, vulnerabilities continue to decrease in new code. This eases the burden of remediation support from the AppSec team allowing them to focus more on strengthening the overall security posture of the organizations.

The Secure Code Warrior Connector for Okta Workflows, along with our learning platform, can help organizations achieve their goal of shifting security left, faster by elevating the security proficiency of the development teams.

Reach out to schedule a demo or check out the documentation to discover more details about the setup and configuration.

‍

At Secure Code Warrior, we are constantly innovating to improve our customer experience and add value through the platform.

This month, we have released new updates to the Courses admin experience, the ability to get early access to new features with less wait time, and SAP:ABAP content.

Now administrators can more easily manage Courses with a better end-user experience, thanks to a powerful tabular view with the ability to perform bulk actions across languages and vulnerability categories. Plus, you can now get early access to new features with the help of a simple on-off toggle.

Let's dive in and find out more!

Create and manage courses more easily with our new Courses creation experience

Now you can easily design and deploy Courses across multiple learning paths and languages through bulk actions. Instead of taking time to replicate the process, you can place more focus on the content and strategy to help your developers learn more effectively.

Currently, Courses creation flow updates are available for company admins to use.

Save time designing Courses with a powerful tabular view and search experience

Course information across all languages and vulnerability categories is now accessible in a single view, making it easier for you to create courses for different development teams quickly.

Thanks to the new tabular view, you can easily see an overview of content at a glance or drill down into the details. Course content is also easier to navigate now, as it is grouped by language and vulnerability categories with additional details, such as activity types, difficulty, and more at each group level.

You can even narrow it down to the details you want to focus on by using the search function, or by applying filters. Plus, table data can be exported into another application or analyzed further by exporting all or filtered rows into a CSV file.

‍

Do more with fewer clicks with bulk actions

You can make bulk changes to the course from one place instead of applying changes across every language. Bulk actions will save admins time and let them focus on what matters—designing the right course experience for developers.

New bulk actions include:

• Add a course focus, such as OWASP Top 10 or specific vulnerability categories for all languages
• Add languages to a course and update content quickly
• Copy, lock or unlock modules for selected or all rows
• Remove languages or modules from the course
• Set up a welcome and end-of-course message in one go for all languages

‍

End-of-course assessment pathways

Now you can tailor end-of-course assessment for each language and manage it from a single view.

You can easily create tailored assessment pathways, based on language and course types, to measure and evaluate skills upon course completion.

Get early access to new features

‍

In the past, if you wanted to know what new features are coming and try them out before general availability, you would need to talk to your Customer Success Managers and wait for our team to turn features on for you.

Now you have control over when and which feature to turn on for your team with just a simple toggle in the Administration tab. No more wait time is needed.

Simply go to Administration > More > Early Access to try it out.

This functionality will be utilized for more features, especially those that involve significant changes to user experiences—allowing you to better control your experience.

Curious what features are available for early access? Check out some of the current options:

> An improved home page view for a more unified experience

> Courses updates:

1. Preview Status mode
2. Bulk actions on course content
3. Global welcome message
4. End-of-course activity improvements

Currently, the Early Access options are available for company admins to use.

Secure ABAP applications with newly released training content

Now developers coding in ABAP can join in on the fun of highly engaging and relevant secure coding training! The new training will help developers improve their secure coding skills and reduce vulnerabilities in ABAP code.

With Secure Code Warrior coding challenges and Missions (hands-on labs), you can provide a program that covers:

1. Self-paced training that developers can enjoy at the time they need it
2. Targeted learning pathways that align with compliance, security frameworks, or developer skill levels
3. Fun coding competitions
4. Secure coding competency assessments

Read more about our ABAP training content here.

------

Interested in trying out Secure Code Warrior but don’t have an account yet? Sign up for a free trial account today to get started.

That’s a wrap on this month’s new capabilities! Follow Secure Code Warrior on Twitter to get updates about the latest releases and improvements.

Today, we are excited to announce that SAP:ABAP training content is available in Secure Code Warrior! You can ensure that your ABAP development teams get the support they need to ship quality code faster, with less rework and fewer vulnerabilities through:

• Self-paced training
• Targeted learning pathways
• Fun coding competitions
• Secure coding competency assessments
• Personalized reports of strengths and weaknesses in secure coding skills

ABAP (Advanced Business Application Programming) is the primary language for 19,000+ enterprises to code their business apps on top of SAP platforms. In total, these enterprises generate up to 87% of total global commerce - amounting to 46 trillion USD. Therefore, securing ABAP is more important now than ever before.

At Secure Code Warrior, we strive to enable developers to secure every business-critical application, including those written in niche languages like ABAP and more common ones like Java.

‍

‍

If you are an existing customer, you can now access the content under Training, Courses, and Tournaments. Don’t hesitate to talk to your Customer Success Manager if you have any question 🙂 .

How Secure Code Warrior helps secure business-critical ABAP applications

Because ABAP is a niche language, it's rarely included in training platforms. Therefore when companies try to train their developers, they do so through overly expensive and inefficient programs, like one-off workshops.

With Secure Code Warrior, you get an ongoing and effective training solution.

Our training content is delivered in developers’ preferred format - code snippets and samples. So you can be confident that they will use and enjoy the content.

Plus, with the depth and breadth of our content and tiered learning system, ABAP developers get the continuous support they need to progressively advance their secure coding skills. This progressive learning experience ensures developers to form the muscle memory and practice what they learn in their projects.

‍

Learn to identify vulnerability and secure code patterns through coding challenges

‍

We know that developers work best in environments they are familiar with. That’s why we present our coding challenges in a code-editor-like interface.

Developers can navigate through files and code lines to locate, identify, and fix ABAP vulnerabilities in functioning codebases. During the training, developers learn to recognize vulnerable code patterns and the right fixes, which results in earlier detection of vulnerability and quicker remediation time.

ABAP is the newest addition to our language offers, the same benefits are available for all other 57 languages (and counting) that we cover on the platform.

I have seen vulnerability remediation happening as a direct result of rolling out Secure Code Warrior® training because my developers will say things like “I remember I learned ‘this’ in Secure Code Warrior® training, so I am creating a ticket to address the security concern here.”

Nicole Smith, Head of Security, Komodo Health

Become a security-savvy developer through immersive real-world simulations

‍

Once ABAP developers get familiar with basic secure coding practices. They can challenge themselves to be security champions by playing Missions.

Missions are our simulated playgrounds for developers to exploit a specific vulnerability. By witnessing how an exploit impacts a functioning app in real-time, they can practice offensive secure coding skills and take that back to protect their projects.

Try out ABAP coding challenges

With the latest content for ABAP, you can provide a progressive training program for developers easily and effectively.

Existing Secure Code Warrior customers can access the training content through Training, Courses, Tournament, and Assessment playmodes.

If your team has not onboarded our solution yet, why not try out our ABAP coding challenges today?

ABAP is one of many languages available

We provide training content for 57 other languages, including the most popular (Java and C++) and the rising stars (GO and Typescript). Check out our full list of supported languages and try out coding challenges in your chosen framework today.