Like many people in the security industry, I and several colleagues made the journey in March to the RSA Conference in San Francisco. Although an extremely busy time of year, it is truly one of my favorite events. One part I particularly look forward to is Bugcrowd's Mayhem at the Mint, which is a chance to relax and have a great time with peers and friends after long conference days.

This year was a little different, though. We had a lot to personally celebrate. As sponsors of the event, we had our own cocktail on the night (Secure Code Sangria, of course), but the thing that really made me want to party was our new partnership with Bugcrowd. It's official: we are joining forces in the fight to educate, empower and enlighten developers on secure coding.

I enjoyed and appreciated the enthusiasm expressed from the wider industry regarding this announcement, particularly the article and podcast episode from ITSPmagazine. In speaking to Bugcrowd's Casey Ellis and Jason Haddix, editor Sean Martin truly captured the essence of why we do what we do: it's because meaningful change takes a crowd. Bugcrowd has long recognized this, and working together to turn software engineers all over the world into security superheroes is a dream come true.

After more than twenty years of breaking stuff, finding and fixing vulnerabilities that have wreaked havoc on the world, it has become more apparent than ever that the conversation around security must change. "Hackers'aren't always the bad guys; their inherent skills are invaluable in the software fortification process, and we need to make a concerted effort to start left. It shouldn't be a novel concept to try out someday, it should be core to the software development lifecycle. To do this, we and Bugcrowd are committed to changing the perception many developers have of security: that it is an inconvenient blocker to building functionality and features.

Security training to date has been inadequate. Far too infrequent, often irrelevant to day-to-day coding activities or simply not engaging the hearts and minds of developers. Secure Code Warrior seeks to change that - learning about secure coding can be fun, and with Bugcrowd's support, this message can be spread far and wide in the community we care so much about and seek to encourage.

Ultimately, we must reach a point where software security is synonymous with software quality; there is simply too much at stake these days to suggest otherwise. And with this partnership, I believe we can get developers actually excited about secure development. A thriving environment of security awareness and a positive culture is key, and I couldn't think of any other company more perfect to get us there.

Watch this space: the security conversation is about to dramatically shift left.

... a third party accessed your repository by using the correct username and password for one of the users with permission to access your repository. We believe that these credentials may have been leaked through another service, as other git hosting services are experiencing a similar attack.

As a user of a web-based service, it's never a great experience to receive an email like that about a potential breach of your personal data. Now, imagine that the data is a code repository representing your hard work, or even the trade secrets of your software. At least 392 (so far) GitHub, Bitbucket and GitLab users received that heart-stopping notification this week, and what's more - their code has been downloaded by the attackers, wiped from the repository and held to ransom. Once the affected users'files are all gone, just one text file remains containing this message:

Unlike most other newsworthy company breaches (and even previous attacks on GitHub) this one wasn't caused by a bug on their platform. Rather, account information was stored insecurely in plaintext and likely leaked from third-party repository management services. Developers were actively storing important password incorrectly, and often reusing the same credentials for multiple high-value accounts.

It would appear the scammers aren't the best and brightest of the programming world, as (at the time of writing) not a single user has paid the ransom to recover their code, and some clever security-minded folks have already found workarounds for affected users to recover deleted code.

Still, this does highlight issues we have known for a long time within the security industry: most developers are simply not sufficiently security-aware, and valuable data could be at risk at any time... even by those who aren't hacking geniuses.

Why is our password management still so poor?

Humans are of course flawed, and we tend to want to make life easier for ourselves. It's certainly much less of a hassle to reuse the same username and password over and over again, and remembering your first puppy's name is far easier than typing "Z7b3#!q0HwXxv29!'just to access your email. However, with so many large-scale cyberattacks taking place constantly, developers really should know better by now.

GitHub's own advice on the matter was straightforward, assessing that this ransom attack would not have taken place if two-factor authentication was in place and that secure password managers were in use. This is absolutely true, but as I keep saying - it is clear that the education must go further. All developers need to understand - at a fundamental level - why certain actions could leave their accounts vulnerable to attack.

Education: The magic pill?

Security-savvy coders understand that a simple security misconfiguration can have devastating consequences, and in the case of this GitHub attack, it seems misconfigured files were instrumental in allowing the attackers to successfully inject malicious skimmers to hunt down the keys to their castles.

Sensitive Data Exposure is also a critical vulnerability to overcome, still sitting at number three in the OWASP Top 10. Storing passwords in plaintext is clear evidence of many not understanding the dangers of doing so, and how easily systems can be breached through brute-force password attacks.

Understanding cryptography (and in particular, cryptographic storage) is an essential component to managing passwords in a code base using iron-clad security. Successfully salting and hashing any stored passwords, forcing their uniqueness, is going to make it far more difficult for situations like this ransom incident to take place.

It is important to understand that our collective attitudes towards security need to change, with more emphasis on adequate education for developers and taking the risk cyber threats seriously. We need to make learning about security a positive and rewarding experience, and I think that will be fundamental to an overall lift in standards for every developer self-assessing their work.

Want to try defeating the vulnerabilities you've read about here? You can play related challenges on Secure Code Warrior right now:

• Security Misconfigurations
• Insecure Cryptographic Storage
• Sensitive Data Exposure

Originally published in Regulation Asia.

With cyberattacks on the rise " affecting every type of organisation in every vertical " the threat of expensive, embarrassing and bottom-line-affecting data breaches is very real. The problem is not getting smaller, it's growing like a tumour.

I'm often asked to provide examples of which organisations are combatting this problem, navigating the "wild west'of cybersecurity and AppSec best practice with particular finesse and mastery. I am finding myself coming back to one answer more often than others: it's the finance industry that is doing it better than most.

Regulation: A driving factor in the finance industry's cybersecurity leadership

One of the reasons the finance sector plays in the AppSec space so well is that they (at least in part) are driven by global, regional and national regulators'concerns for the universal " not to mention catastrophic " impacts that could result from a successful cybersecurity attack or data theft.

The BCBS (Basel Committee on Banking Supervision) published a report in December that details the range of observed bank, regulatory and supervisory cyber-resilience practices across multiple jurisdictions. Among its key findings was a cybersecurity skills shortage challenge, a factor that only a slim few jurisdictions have worked to confront by implementing specific cyber certifications.

"Some jurisdictions have IT-specific standards that address the responsibilities of the IT workforce and information security functions, with particular attention to cybersecurity workforce training and competencies," the report said. But most jurisdictions are in the "early stages" of implementing supervisory practices to monitor a bank's cyber-workforce skills and resources.

For the most part, regulatory schemes require regulated entities to manage risks, but there is rarely a clear pathway to successfully mitigating this risk. They do not set specific requirements (or indeed, benchmarks) to address cybersecurity workforce skills and resources. Most regulators assess the cybersecurity workforce of institutions through onsite inspections, where self-assessment questionnaires are common practice, and training processes are particularly scrutinised, but only in a few jurisdictions do regulations specifically address IT staff's roles and responsibilities. Put simply, the margin for error is great and the emphasis on the right training and subsequent assessment of skills is rather small.

In Japan and South Korea, public authorities have set guidelines on appropriate cybersecurity workforce management. In most other jurisdictions, however, regulatory requirements for cyber-workforce management are limited to supervisory expectations, where there is often no assessment by supervisors of cybersecurity skills and staff training at regulated organisations.

Only Hong Kong, Singapore and the UK have issued dedicated frameworks to certify cyber-workforce skills and competencies. While words like "compliance" and "certification" tend to send a cold shiver down the spine of your average creative, problem-solving developer tasked with building great software features (with them, security is often seen as someone else's problem, namely the security team), the massive amounts of sensitive data many regulated entities hold is simply too valuable to leave in the hands of those where skills are "assumed'rather than properly verified.

Fortunately, many banking and financial institutions recognise this without necessarily relying upon an obvious regulatory pathway. The regulations certainly provide an overview of the end-result expectations (i.e. secure software), but they have identified that achieving this requires circumventing the cybersecurity skills shortage by training developers, nurturing their relationship with existing AppSec professionals and building a positive security culture that breeds responsibility and ownership.

Why does the financial industry have the cybersecurity "X-factor'?

There are a few elements at play for firms in the banking, financial services and insurance industries, which come together as pillars of strength on which their leadership position in the cybersecurity landscape is based.

Naturally, as the gatekeepers of the world's finances (not to mention millions of highly sensitive data records), they are typically very compliance-driven and regulated organisations " updated guidelines, regulations and requirements are expected and planned for in a meaningful way. As a result, they took like ducks to water with the evolving needs of mitigating cyber risk, boasting some of the most stringent cybersecurity best practice policies, as well as end-to-end processes for reducing their exposure to potential attack.

So, what are financial institutions doing differently to others? In my experience, they have laid the groundwork to be more security-aware than others, identifying a need for and dedicating resources to holistic training programmes for not just AppSec professionals and penetration testers, but also their (typically very large and globally scattered) development teams.

With cybersecurity relatively new in most organisations, it is refreshing that financial institutions are truly open-minded and innovative in their quest to provide safe, secure software. Many have seen the benefit of upskilling the development cohort with engaging training that takes them out of the classroom and into a hands-on, relevant learning experience that helps them not just fix problems, but understand the importance of secure coding in general.

After all, secure coding is a key ingredient in forging a robust, functional relationship between developers and the AppSec team, as well as maintaining a robust security culture within the business. Another key factor that drives a successful security programme is ensuring key stakeholders are on-board and seeing the benefit, even if they are not security professionals themselves.

Financial institutions tend to communicate well with executive management, ensuring that top-level decision-makers understand that security processes are not "set and forget'measures; they must evolve as rapidly as the technology being used and adapt to variable risks.

It may cost time and money now, but with vulnerabilities thirty times more expensive to fix in committed code, a well-rounded security programme " that includes training from the ground-up " is a long-term money saver: it is far cheaper when security issues are fixed as they are written by security-aware developers.

Security standards are starting to keep pace with growing risk

A significant driver of cyber compliance for the finance industry comes from the PCI Security Standards Council, which remains committed to helping financial organisations implement viable security policies and uphold guidelines in all areas. They have been a force for good in helping this vertical achieve among the highest standards of security in payments software.

However, it has to be said that many of our financial industry clients have actually outdone even the current PCI Security Standards Council guidelines. While these guidelines recommend training for developers, (as mentioned earlier with other examples of regulatory information) they don't specify a particular type or a certain benchmark to meet to indicate the training has been effective.

With many vulnerabilities like SQL injection and cross-site scripting (XSS) having hung around for more than twenty years (and are still causing problems in 2019), it is clear that not all training is equal or effective. By adopting hands-on, gamified secure training, banks and other financial services firms are seeing far better results and real reduction in the vulnerabilities that can wreak havoc if exploited.

A great example is how US banking institution, Capital One, has utilised gamified training techniques as part of its innovative Tech College and certification system. According to Russell Wolfe, their Director of Cybersecurity & Cloud Computing Education in a recent webinar, the voluntary training programmes and coding tournaments gained traction very quickly, with unprecedented demand and organic motivation from peers to get certified and assist in upskilling others.

What can regulators do to ensure cybersecurity workforces are adequately trained?

Regulators around the world can really "go one better'on their existing cyber regulation policies and guidelines, simply by outlining accepted training methodologies and standards that those in control of protecting our data must meet. At the moment, it appears there is a general reference to a training requirement in most regulatory policies, but there is little follow-up to ensure those moving through any prescribed training are absorbing the content and techniques required to really assist in the fight against cyber threats.

The recent move by the MAS (Monetary Authority of Singapore) to include the adoption of security awareness training programmes and secure software development best practices in the latest iteration of its Technology Risk Guidelines, however, is encouraging. Once the guidelines enter into force, they will require financial institutions to ensure their software developers are trained to apply secure coding, source code review and AppSec testing standards when developing software, which should go a long way towards minimising bugs and vulnerabilities.

For me, training the development cohort with hands-on, real-world techniques is by far the most engaging and relevant to their jobs, while laying the foundations for the robust security culture each and every organisation must create before it's too late.

Originally published on DevOps.com.

In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability (along with the right designing tools, techniques and tactics to stop it). However, this forward-looking focus can have the surprising effect of dampening our overall security awareness, blinding us to deep-seated dangers that exist all around, and which attackers are all too happy to exploit.

I often compare modern cybersecurity to a suit of Kevlar armor. The seemingly ethereal properties of Kevlar can block high-velocity rounds and all manner of modern, powerful weaponry. It may even make a wearer feel somewhat invincible. However, a comparatively ancient bow and arrow weapon system, first crafted sometime around 1000 B.C., can often penetrate that protection. A sharp knife, probably the second oldest weapon in the world behind rocks, can slice right though Kevlar as easily as if it were shredding a cotton sweatshirt. And then there's the little matter of Kevlar not being able to protect every single millimeter of the human body. If an attacker can find any gap to deliver a damaging blow, they will"much like small, exploitable areas in software.

In cybersecurity, many organizations are similarly vulnerable to flaws on systems that are eight or 10 years old, which in modern computing terms just about qualifies them for a gold watch and a pension. But if you think flaws on these elderly systems are harmless, then you've probably got a blue screen of death or two in your future.

A Vulnerability for a Veteran

One of the oldest and most used JavaScript libraries is jQuery, an open source resource that helps with everything from event handling, to DOM tree traversal and manipulation, to generating animations. It's quite a workhorse, and has been used for many years. People assume that because the library is so established at this point, that it must have been completely vetted, with any vulnerabilities removed.

Sadly, this is not the case. By default, most applications that rely on jQuery use the internal library's instructions for authentication. For example, with Apache servers, this means checking the .htaccess files. Few developers designing programs that use Apache probably thought to check to make sure that Apache server updates included .htaccess. After all, why would Apache remove that critical component, which has been a bedrock of security for years?

As strange as it may seem, that is exactly what Apache did in version 2.3.9. Apparently, having to check the .htaccess configuration files every time a program needed to run was slowing things down too much. Removing it improved overall Apache performance, but also created a vulnerability that most people didn't know about. If developers didn't bother to check to see if their apps could still reach the .htaccess files, most requests would simply be accepted without scrutiny.

Recently, experts discovered that flaw and noted that using it would allow unauthorized users to upload and run shells or almost any type of code on supposedly secure systems. This led to the creation of a vulnerability alert designated CVE-2018-9206 in October. But, the ease at which the flaw was discovered by a security researcher implies that professional hackers, whose sole aim is to search for vulnerabilities such as this, probably already have discovered it. After all, despite the publicity, patches and fixes brought about in the aftermath, a similar high-impact attack happened just a few weeks later, in which Bitcoin-thieving malware was unleashed on a popular NPM lib downloaded by millions every week.

The Butler Did It

Like jQuery, Jenkins is an open source offering, and one of the most popular of its kind. With its helpful servant-like name, it makes sense that Jenkins is used as an automation server by development teams in many industries. When Jenkins is functioning correctly, it's an extremely helpful tool. However, newly discovered flaws, and one recently uncovered crypto mining operation that is truly massive in scale, suggests that Jenkins was also doing a lot of work for the bad guys.

One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It's a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.

Even on patched servers, exploits exist. For example, when running Jenkins in a Windows environment, by default it uses the NT AUTHORITY\SYSTEM account to authorize users. This is dangerous because SYSTEM is granted full permissions on Windows servers. Developers can change the authority account, but often don't. Their logic not to do so is based on the fact that Jenkins has been around forever, so people figure that any vulnerabilities have been patched a long time ago.

Most recently, a hacker used these aging Jenkins vulnerabilities to compromise several servers. The goal was adding a crypto miner program on every vulnerable Jenkins instance they could find. The miners took up valuable computing resources in their constant search for cryptocurrency. So far, they have found approximately 10,800 Monero crypto coins, with a value of almost $3.5 million.

What is Old is New Again

In both of these examples, vulnerabilities are being exploited by opportunistic attackers on platforms that many people consider to be safe. On the defensive side, the lack of security-aware development is allowing these hackers to breathe new life into old tricks. And despite a new round of success using aging vulnerabilities, many organizations have no plan in place to stop this vicious cycle.

Just because something is old does not mean that it's harmless. And just because common libraries and resources have been around for years doesn't mean that they are completely secure (for example, the No. 9 entry in the current OWASP top 10 is dedicated to dealing with Using Components With Known Vulnerabilities). Only through diligence and constant security training can we protect ourselves not only from dangerous threats creeping over the horizon, but also those which have already settled insidiously into our own backyards.

Originally published in CSO Online

As a (semi-retired) ethical hacker, security professional and all-round computer geek, you might say I care a lot about technology. I care about how it was crafted, what it does and how it's going to make some aspect of our lives better or more efficient. I look "under the hood'of devices all the time, seeing some of the best (and worst) examples of code out there. Recently, I looked at how my air-con system could be controlled remotely with an Android app (imagine my surprise when I discovered that anyone on the WiFi network could control that thing without any authentication whatsoever).

Software security is always front-of-mind for me, as is the very real danger posed by our increasingly digital, personal information-sharing lifestyles. After all, we are in a largely unregulated, unsupervised and blissfully ignored territory. We're in the Wild West.

As a collective society, we're not looking under the hood of the technology we use every day. Although popular and highly acclaimed TV series like Mr. Robot help with general awareness, we're not security-minded... in fact, most of us have no idea how secure the software is within the myriad of applications, services and increasingly connected things we purchase and use. It's not even that we inherently trust them - we simply don't think about them at all.

Sony PlayStation Network (PSN), Ticketmaster, Yahoo!, Facebook, Target: every single one of these widely-used companies has been a victim of a data breach. Their software vulnerabilities were exploited, and millions upon millions of customer records were exposed. These examples represent a fraction of the global breaches that have taken place in the last ten years. They are a costly consequence of poor software security that allows the bad guys to steal our precious information.

When most people consider data breaches, they think about information security breaches, They are understood to be a nightmare for the company breached and inconvenient for those whose personal details have been impacted, but seriously, what's the big deal? If security continues to be ignored, are the consequences really that big? Nothing that major has happened so far - data breaches have severe impacts for the companies responsible for them, but it's their problem, right? They lose business, they lose consumer trust; it's ultimately their job to sort it out and pay for the damage.

Software security should be every organization's priority.

There's a fairly simple reason as to why software security isn't the number one concern for every organization out there with a dev team: not enough people have lost their lives yet and there's not enough knowledge about the risks.

Morbid? Perhaps. But it's the honest truth. Regulation, build standards and law-changing attention is paid (like from, for example, government agencies) when there is a real human cost.

Take a bridge, for example. Civil engineers (a line of work that is hundreds of years old) consider safety as a core part of constructing a bridge. Their approach goes far beyond aesthetics and basic functionality. Every bridge built is expected to adhere to stringent safety regulations, with both the civil engineering profession and society as a whole learning over time to expect a high level of safety. A bridge today that does not meet the safety requirements is considered dangerous and unusable. This is still an evolution we need to get to within software engineering.

By way of a more modern example, let's take a look at the toy industry. The 1950s saw a huge surge in toy production and sales thanks to the post-war baby boom. Interestingly, the amount of emergency room visits involving toy-related incidents was also reported to have increased during this time. Toy arrows were causing eye injuries, small toys (and detachable pieces from larger toys) were being ingested, and toy ovens marketed to little girls were capable of heating to higher temperatures than regular home ovens.

It was somewhat of a "Wild West'out there, with little regulation except for a few isolated bans and product recalls in the most dire of circumstances. Toy makers were essentially free to produce whatever toys they wished, with any concerns for safety typically flagged after several reported incidents had already occured. It wasn't until bills like Richard Nixon's 1969 Toy Safety Act were passed into law that the testing and subsequent banning of hazardous toys became standard, in the US and around the world. While accidents will still happen, today the general process of toy manufacturing adopts a "safety first" policy, and our kids are in far less potential danger.

In software security right now, we're in the Wild West. Apart from obvious laws and regulations in relation to privacy (especially recently with the GDPR) and protection of customer data as well as mandatory breach reporting legislation in some countries, very little is said and done in the mainstream business or community about the level of security built into software. Even those laws relate more to company responsibility than they do to the actual software being regulated, or having a compulsory standard of security to meet.

We will get there, but it may require a path of destruction first.

Gartner estimates that there will be 8.4 billion internet-connected devices in use by 2020; a figure that represents a 31 percent increase since 2016. This includes consumer electronics, as well as things like medical devices and industry-specific equipment. That's a heck of a lot of opportunities for a hacker.

Imagine the software running someone's pacemaker is insecure. A hacker could break in and  potentially stop the heart of their victim (think that's ridiculous? Doctors disabled the WiFi in Dick Cheney's pacemaker to thwart potential assassination via hacking). A connected microwave or kettle could be blown up remotely (along with all manner of the Internet of Things devices we enjoy in our homes), or a connected electric car could have its brakes disabled. This might sound like a far-fetched Hollywood action movie, but if the software of any of these advanced pieces of connected technology can be breached, we really do have a potential disaster on our hands - just like the threats we've already covered with the explosive ramifications of cyberattacks in the oil and gas industry.

We can preempt the dire consequences of malicious hacking as our lives become more and more digitally dependent. It all starts with getting developers more excited about secure coding, and getting serious about growing a strong security mindset and culture in development teams.

Your software revolution starts here. The banking industry is leading the way in embracing gamified training in the fight against bad code, in a truly innovative approach that turns traditional (read: boring) training on its head. In fact, each of the top six banks in Australia are currently engaging their developers this way, igniting their security mindset. Check out what our client, IAG Group did with their next-level tournament.

Every year on Australia Day, most Aussies spent their time with prawns, BBQ, lamb and beaching in the sun. Every year on that day, I reflect on the last twelve months, both personally and professionally. The older my daughter and the company gets, the more I realise there are so many similarities between a startup journey and the "first-time" parent journey. I am in my fourth year for both now.

"Your child is growing up. Have you noticed that your four-year-old is becoming more independent and self-confident? Most children this age begin to develop greater independence, self-control, and creativity. They are content to play with their toys for longer periods of time, are eager to try new things, and when they get frustrated, are better able to express their emotions."

Every now and then, I get asked questions... and I honestly don't know the answer to a lot of them.

It never ceases to amaze me; I am asked questions that seem so trivial to somebody growing up, but they're so complex for me, the adult, to answer sensibly: "Dad, how do our mouth and tongue allow us to speak?", "Why is it daylight in Australia and night in Belgium right now?". You suddenly realise they are much smarter and more curious than you thought. And then there's our startup, asking existential questions like "Why does Secure Code Warrior exist?", "How is what I am doing contributing to company success?", "What do we want to be when we grow up in five years?". Apart from investors and existing staff, a vast number of job applicants have really forced me to have solid answers for these type of questions.

"Our vision is to empower developers to be the first line of defense in their organization by making security highly visible and providing them with the skills and tools to write secure code from the beginning."

In the past twelve months, we've continued on this mission by more than tripling our staff, more than doubling our revenue, adding customers in twenty-one different countries and adding more than ten different programming frameworks to our Secure Code Warrior platform.  

Making mistakes is part of growing up.

We all strive to do the right thing all the time - but sometimes mistakes are made and I need to feel comfortable allowing this. My four-year-old is a "free-spirited child", which I think is a euphemism for "a stubborn smarty-pants". But, even she realises that she is not always right and listening to others could be useful. I take the view that making a mistake shows that decisions are actually being made, and that's a good thing. It clearly demonstrates the independence and self-confidence I spoke about earlier. At work, I ask the ones who do not agree with my decisions, to support my decision and allow me to make mistakes. I guess it's better to regret something you have done, than to regret something you haven't done (quote shamelessly stolen from Orbital).

Pushing boundaries and warping levels.

Since she could walk, I've been the dad encouraging her to climb up a 2m wall on the playground, turn around and jump off without a doubt. Going down head-first on the slide, taking her snorkelling on the Great Barrier Reef before she could properly swim. Oh yeah ... I got quite a few evil looks from other parents and her mum ;-). I wasn't a big daredevil when I was young ... but once I started trusting my own instinct at twenty-five years old, I know pushing my own boundaries would make me go faster. I am sure she'll thank me when she is older.

As a startup CEO, I feel the same... coaching our team to take risks, push boundaries, break barriers and warp levels. "We can't possibly reach these targets!", "We need rules and policies, etc.". I've surrounded myself with both risk-taking and risk-averse people (you know who you are), and I think it's my job to consider their opinions... and then take a leap and trust my instincts.  

I am sure the year ahead is going to be another rollercoaster. The first time reading and counting, the first time spending full days in school... and probably a lot more questions I can't answer. With Secure Code Warrior, we're going to break the barrier of 100 employees in the next few months, our first customers will have spent more than three years on our platform, and we'll be signing up our first customer in China.

I am sure there'll be many challenges ahead, but we're an awesome team, and we're ready for it.

Imagine crafting something from scratch, wielding your skills and experience with mastery to make a small, but special, mark on the world. Whether alone or part of a team, you place your heart and soul into building something from nothing. You spend hundreds - maybe even thousands - of hours on it, making sure your baby is the best it can be. Upon completion, that wave of accomplishment can feel like a reward all on its own.

Now, imagine a spoilsport comes along and tells you it's not that great. Perhaps they go a step further and tell you that, no, in spite of the energy, time and love you have sacrificed, it's actually not even usable: it's broken. They have, in essence, told you your baby is ugly.

The above scenario is bound to cause some tension; after all, who wants their hard work picked apart and condemned as inadequate? Sadly, for many developers, this can be the reality of their relationship with the AppSec team. A developer has a primary responsibility of building software that is functional, feature-rich and delivered within strict project deadlines. Security is rarely the priority, and can even be seen as a blocker to rapid delivery and innovation. AppSec has the unenviable task of meticulously checking code, pen-testing and then reporting the bad news: the presence of security vulnerabilities in code that is often already committed. It's an expensive process in an environment that is often stretched for resources and time, with the setup bound to cause a rift between two teams that have the same goal, but speak such different languages that they seem at loggerheads.

Don't you think it's time we gave security a makeover? It's as simple as changing the conversation and making everything a little more positive (not to mention fun!) for both sides, especially the development team.

Out of the classroom, into the game arena

With many developers completing vocational training without learning much on coding securely, it is often the case that their first touch-point with security education is upon entering the workforce. Classroom-based training is one oft-used solution, but it takes away precious time from feature delivery (and, let's face it: if the teacher and content are under-stimulating, it can be an easily forgotten waste of time for everyone). There are also video courses, paper-based exams and generic company security policy education... all of which can be so non-specific as to be useless in the day-to-day working lives of the average developer.

Too often, it is treated as a "tick the box and move on'compliance exercise, and too often it has the opposite effect: it just drives a wider rift between AppSec and the dev team. After all, it doesn't appear that conventional training is having the positive effect on security culture and compliance that we as an industry are so desperately seeking. We keep making the same mistakes.

According to the Common Weakness Enumeration (CWE) community, there are more than 700 common software security weaknesses to fight against. Some, like SQL injection, are like cockroaches that haven't been squashed despite their existence for more than twenty years. We know how to fix it; the training is there to empower developers to stop it and so many others, yet pen-testing and manual code review processes continually identify these violations.

Perhaps we've been looking at it all wrong, and we as an industry need to tackle viable education from a different angle... one that harnesses the amazing skills so valued in our developers. They are creative, inquisitive problem-solvers who love a challenge. To gamify security training is to speak their language, to allow them to practice by doing - and who knows, they may just fall in love with security along the way.

A little healthy competition

A core reliance on (rather inaccurate) tools, expensive pen-testing and scarce AppSec specialists is going to plunge us deeper into the security black hole. Too much of our lives and privacy exists online for companies to continue throwing caution to the wind with the virtual fortresses that protect our data. As the digital transformation of our world increases our dependence on software, we need to turn to the superheroes we have had sitting in the office all along: the development team.

Gamified training, in relevant languages and frameworks, is a potent tool for AppSec managers to start transforming security culture within the business. From the training, developers can flex their newly-built security muscles in a fun tournament setting, one that can be as exciting as your imagination can conjure: just take a look at how IAG's "Game of Codes' got everyone talking about security within their organization.

Secure Code Warrior's tournament module provides more than just a nice little cap on a measured training commitment: it is a platform from which each developer can validate their skills, see how far they have advanced since training commenced, as well as identify areas that may need improvement. The competition aspect really acts as a motivator to engage positively with security, using reward and recognition to support the growth of a robust security culture within the team and wider business.

Injecting a little fun into what can be seen as a laborious - if not daunting - task, can go a long way in changing negative mindsets and inspiring continued participation. After all, who doesn't love the glory of scoring more points than their peers in a (healthy) competitive environment?

Champions walk among you

Gamified training and subsequent tournaments help immensely in driving a positive security culture, with AppSec and development teams gaining much more insight into each other's day-to-day work. A secure developer is an asset, fixing common vulnerabilities and leaving the complex issues to those scarce AppSec specialists on the ground. Better relationships grow and thrive, and the precious security budget isn't chewed up fixing a "Groundhog Day'scenario of the same errors over and over.

There's another powerful byproduct, however: the revelation of the security champions you never knew you had. Tournaments can uncover those that not only have an aptitude for security, but actively display a passion for it. These champions are vital in keeping the momentum going and acting as a point of contact between teams, overseeing peers and upholding best practice policies. Implementing a solid champion program, one that includes recognition and executive support, is a feather in the cap of the organization, as well as a powerful inclusion for the individual's CV and future career.

The bottom line? We must demand better outcomes in security testing. Less common errors, more support for those on the front lines. Why not see how a developer tournament can get you there sooner than you think?

2018 has been a mammoth year for cybersecurity professionals. Despite the warnings to take security more seriously, the constant press surrounding nurturing more security industry talent and general attempts at making organizations more cyber-aware, we are left staring at the smoking craters left behind by hundreds of cyberattacks, representing large-scale data breaches and consumer mistrust in some very well-known household names. In the first half of 2018 alone, 4.5 billion data records were compromised in 945 separate incidents.

I've said it before, many times: we can do better. However, the real battle we face isn't against script kiddies, dangerous organized cybercrime syndicates, or mysterious hoodie-clad figures typing away on laptops - the fight lies in getting more people to care that these breaches are happening at all.

GDPR compliance is a good start, but it won't have a huge short-term effect.

The European Union's General Data Protection Regulation (GDPR) laws are now in full swing; a looming threat over organizations who don't take data protection seriously. With huge fines applying for those found to be non-compliant, this was meant to act as a kick in the backside for companies to tighten their security practices, treat customer data with more respect and come up with a strategy to mitigate against cyberattacks.

Some organizations have been warned of huge fines to come, but we are yet to see true fallout as a result of failure to comply with GDPR. No bankrupting penalties, just a whole lot of pop-ups to click through for us web users. This is in part because legal processes take a lot of time, with a lot of opportunities to appeal - any companies that may have been made an example of are likely engaged in a months-, or years-long, legal battle. Ending a nightmare year for Facebook, they reported another data breach recently: an API bug exposing the private photos of 6.8 million users to 1500 unauthorized applications. It was found and patched within two weeks, yet data protection agencies and the public were only made aware of the violation months later. GDPR laws require notification of a breach with 72 hours, so it raises a lot of questions on just how influential and effective these laws really are at present.

And of course, breaches elsewhere have not stopped: November's Marriott breach revealed a whopping 500 million data records were compromised, and, perhaps even more concerning, that the attackers had accessed their systems for four years before being discovered. It should be noted, however, that Marriott seems to be engaging in some damage-control: they've offered victims a free 12-month subscription to WebWatcher, a credit monitoring tool... but with 500 million records for hackers to sift through, it does remain to be seen whether one year will be enough time to monitor anything meaningful for most; it may be some years before your data is highlighted for unscrupulous use, after all.

Long-term, regulations like GDPR will drive positive change if they are enforced. When companies are hit with a significant financial penalty (or, indeed, class action lawsuits from customers whose data has been compromised) or profit downturn on a long enough scale, I believe we will see a frenetic focus on fortifying online databases from most companies.

Financial institutions will continue leading the way in short-term positive change.

It may not come as much of a surprise that financial institutions - as the gatekeepers of the world's hard-earned cash - have some of the most stringent cybersecurity best practice policies, as well as end-to-end processes for reducing their risk.

A significant driver of this compliance comes from the PCI Security Standards Council, who remain committed to helping financial organizations implement viable security policy and uphold guidelines in all areas. They have been a force for good in helping this vertical achieve among the highest standards of security in payment software.

So, what are financial institutions doing differently to others? In my experience, they are generally more security-aware, dedicating resources to holistic training programs for not just AppSec professionals and pen-testers, but also their (typically very large and globally scattered) development teams. They ensure that top-level decision-makers understand that security processes are not "set and forget'measures; they must evolve as rapidly as the technology being used and adapt to variable risks.

More organizations will transform their security pipeline.

Compared to other branches of IT, AppSec is relatively young. It's hard being the new kid: you're easily misunderstood and may not have formed the key relationships you need just yet. However, I believe with each passing year, it is getting easier for AppSec to find its place in even the most antiquated organizations that are resistant to change.

It has become more apparent that companies cannot make security compliance a final, last-minute step in their software processes. There must be checks and measures from point-to-point, with more concentration on aggregating data and providing more visibility to the executive levels of the business. Without this, security will remain out of sight, out of mind for most. And in that scenario, it is virtually impossible to gather the resources needed to plan for risk.

The good news is, more organizations than ever are spotting their own cyberattacks and working to fix them. The bad news? That process is taking an average of eighty-five days.

Pen-testing tools and manual code review is arduous, expensive and slow in a time where rapid innovation and feature production is a must in the technology sphere. Security awareness must carry through from the beginning: from the moment a developer writes the code in the first place.

Our industry will recognize the main problem: We need people to care more.

Here's the thing: I could conservatively count twenty people in my network who have stayed in a Marriott hotel at some point in the last four years. With 500 million records stolen over that time, there is a good chance their data was part of that theft. Everything from current contact information, still-valid credit card numbers and passport information could be for sale right now on the dark web. However, their care factor was basically zero.

And, well, it's easy to be complacent when in such a large-scale data heist, you're essentially a needle in a haystack.

The real problem, though? The companies that have failed to keep their own customers'data safe, face very little in the way of repercussions. Does their stock price take a hit immediately following the incident? You bet it does. Target, Equifax and now Marriott could all attest to that. However, a twelve-month overview shows the bounce back to normal is fairly swift. A couple of years later, and financially, all is forgiven.

Until there are serious repercussions: huge fines, tighter regulations and significant loss of business, AppSec will be an industry that must constantly fight to convey the severity of the growing cyber risks to which a company is exposed.

I fear it will get much worse before it gets better, so it is of utmost importance that we work to build security-aware developers and robust security cultures on the front lines of an organization's tech teams. Keep it front-of-mind, and keep striving for a higher standard of software security.

27th Jan 2018. Secure Code Warrior's birthday falls one day after Australia Day. I realised while contemplating another fantastic year that I actually have two three year olds in my life, one business and one human... with remarkable similarities:

• They are trouble to put to bed in the evening without a proper routine

"Just reading that last email which just came in ... or wait, I quickly need to sync on the phone with our team in the US... or this proposal really needs to go out by tonight. Damn. It's past midnight again."

• They make you so proud when they achieve something

Even if you didn't sleep properly for 3 weeks, had no time to exercise or just had to clean-up a mess... but your pilot demonstrated the impact on security skills of developers and the customer is happy to commit working with us for another three years! BOOM! Energy peaks. And cakes everywhere. Suddenly, the lack of sleep doesn't matter so much.

• They grow up so quickly

Gone are the days where you could sneak out with the team to Bali and work from the beach house on the next features of the platform. Our start-up has grown between 4-6 fold in the last year (depending if you measure staff, customers or revenue) with engineering in Sydney (AU) and Bruges (BE) and sales and marketing in USA, Europe and Australia. I remember a year ago when I was really excited having one of the big Australian banks as a customer. Today, we're working with 10 of the top 100 global financial institutions as well as some of the key telecom and technology companies that are building the next generation of online services (note: I am still really proud of the Aussie banks, who were our first customers!).

We've grown up so fast on so many fronts but one of the key milestones last year was actually defining a vision for our company. In the early years, we were so focused on building, executing and making sure there was cash that we often forget to stop and reflect on exactly what we want to achieve. The more people join Secure Code Warrior and the more customers we brought on board, the more important it was to have a consistent vision and understand where we are going. We did that in 2017.

Another key milestone was technology related. We realised early on that building the skills of a developer is only the start of the secure coding journey. They need tools around them to make security embedded and easy rather than an afterthought or something that you think of when you're done writing the code. No, security needs to be built from the start, while writing code.

Our team has worked very hard on writing security coaching plug-ins for the most common IDE's (IntelliJ, Visual Studio, Android Studio to name a few) that will actually help the developer to write more secure code. Not by solely pointing out potential security weaknesses but to really be a coach and jumping in when developers are writing code that is not aligned with leading practices in security. The security coaching plug-in is called Sensei and it truly allows a developer to be trained on-the-spot (micro-learning) and in some cases, it will offer an auto-correct option to fix code instantly.

I am really excited about what the next 12 months are going to bring. We are already seeing that software security is no longer just the concern of the biggest developer-heavy companies like banks, telecom or technology companies. Organisations of all types continue to be compromised by software weaknesses and although SQL injection might finally die, there are a range of other ones waiting to take its place.

There is now a heightened expectation from customers, markets and boards across all industries that companies protect the security of their code. Compliance will keep pushing organisations in this direction too (eg. GDPR for anyone doing business in Europe, Data Breach laws coming in Australia etc.)

This means I am confident our SCW platform will continue its rapid growth across the world and across new industries. That's good news for our business of course, but it is also helping my team to deliver on our vision, which I believe is very worthwhile for the software era that we live in.

Developers using our tools really can and are taking a more proactive role in the security of their company. They have the skills and tools to write secure code, to be the first line of defence for their company.

I feel the same way about being a parent of a three year old and CEO of Secure Code Warrior: every year is better than the last. I can't wait to see how the four year old develops!

Our vision is to empower developers to be the first line of defence in their organisation by making security highly visible and providing them with the skills and tools to write secure code from the beginning.