Only 25% percent of businesses currently think that delivering security is the same thing as delivering quality. Of course, the debate about how to classify security vis a vis quality has been raging for years, and it’s possible that some of the other 75% of companies simply mean that their security and QA are distinct in some meaningful way. On the other hand, it seems more likely that most of these businesses mean that, from their perspective, it’s possible to deliver quality code that is not secure.
This may seem like a fairly semantic discussion, but the discrepancy between code security and code quality is actually rooted in entrenched business realities that often lead to companies rolling out software that’s vulnerable to cyber attacks. Because developers don’t treat security as a quality issue, they don’t tend to roll security remediation into their normal development lifecycles, and they’re often loath to let release schedules slip as a result of concerns raised by the security team. This approach often leads to buggy software, slow time-to-market, and unnecessary intra-operational disruptions. The question is: could this state of affairs be remedied by reconnecting security and quality from a development perspective?
Secure Code vs. Quality Code
Before we address that question directly, let’s very quickly sketch out the ways that security and quality are deployed as concepts. In general, quality code is meant to refer to code that actually performs the functions that it’s designed and built to perform. If you rolled out an e-commerce platform and some users couldn't get the system to accept their credit card information, this would be a (significant) quality issue. This also applies to smaller-scale bugs that interfere with functionality and might irritate a user—potentially to the point of convincing them to abandon the app or platform. For most development teams, these quality issues are built in to the scope of the project, and they’ll address these issues on an ongoing basis and during review periods.
A security issue, on the other hand, would be a form field in an app where users can inject malicious in order to steal information or break things. Though a security flaw that enabled hackers to see an unencrypted list of other users’ passwords, e.g., could easily be thought of as something that impacts the functionality of the app, these two areas have typically been considered separate. As such, while a development team might take the emergence of quality issue in stride, when someone uncovers an area where cross site scripting (XSS) or another attack is possible, the issue isn’t dealt with in the same way that quality issues are. On the contrary, they’re likely to be addressed in a separate, potentially even siloized process—if they’re addressed at all. Because these aren’t considered or labelled as code quality issues, they may simply languish, resulting in an increased risk of successful cyber attacks when the product, app, or update is eventually pushed out.
Why DevOps Usually Wins Out over SecOps
Based on how security and quality are framed above, it’s easy to imagine why this discrepancy in how issues are dealt with could lead to conflict. For instance, if SecOps believes that it’s critical that a certain security flaw be addressed and DevOps doesn’t think it’s a serious issue, a decisionmaker will ultimately have to make a choice: sacrifice your time-to-market and your budget on what you otherwise consider a quality piece of code in order to fix a security issue, or send a potentially risky product out into the world. Sure, your organization is in a position to establish its own risk appetite, but you might also be risking the information of your customers or users without their knowing it.
This is really a no-win situation, but, when push comes to shove, time-to-market tends to win out, and remediation takes a back seat. You could chalk this up to any number of reasons, but it essentially boils down to the fact that the value of the developers’ preference for keeping things moving is fairly obvious, and the value of the security concerns on the other side can be obscure or invisible.
This situation is less than ideal—so how do companies break out of this cycle and align quality with security, rather than pitting them against one another?
How to Integrate Security with Code Quality
For starters, let’s think about what it would look like to think of security and quality as being the same. In this scenario, quality checks on code would assure:
- Correct functionality from a user perspective, covering the full range of whatever the app is designed to do;
- A minimum of bugs that make that functionality harder to access;
- Protection against potential cyber attacks or other attempted intrusions;
- Architecture that facilitates both functionality and protection, in current and future incarnations of the software.
Essentially, security concerns would be rolled into the QA process, and they’d be addressed the same way other bugs and broken functionality are. This might involve building penetration tests and time for remediation into your development lifecycle—just as it might involve using technology like application shielding to cover bugs during the remediation process.
Application shielding in particular has the potential to be an powerful tool for creating alignment between security and quality. By setting HTTP traffic rules on the fly in order to cover your known vulnerabilities at the endpoint level, application shielding makes it possible for you to remediate code at your own pace. Though the code on your servers might still contain issues that present security risks, the code that users (and attackers) see is obfuscated in such a way that the presence or absence of a particular vulnerability can’t even be determined. Unlike web application firewalls (WAFs), this technology doesn’t produce false positives that restrict or slow down innocent web traffic—in fact, they can make your app or site function more quickly.
With this kind of technology in place and properly managed, the time-to-market considerations that tend to hamper security protocols vanish immediately. Sure, security concerns will still crop up, but the urgency for remediation simply isn’t there anymore. For code that can’t be fixed, or for systems that rely on legacy apps that won’t be receiving security updates anymore, this also enables you to extend their shelf lives more or less indefinitely.
Naturally, no single piece of software can magically eliminate every conceivable security threat, but we can take this technology as an example of a system that can facilitate a redefinition of quality to include security. Once you’ve covered existing vulnerabilities and removed the time pressure to address security concerns (without which concerns the security issues would probably languish un-remediated), you might find that you suddenly have the freedom to make proactive adjustments to the way you develop products and push out updates. Instead of keeping your processes rigid because you simply don't have the time or resources to do otherwise, you can let the application shield protect your endpoints while the SecOps team instead spends it energy working with DevOps to redefine quality control.
At the end of the day, this might take a form fairly similar to what we sketched out earlier in the section: DevOps and SecOps work together to identify quality control issues—including functionality, UX, and security—and they deal with those issues in a systematic, fully integrated way. Because your known vulnerabilities are covered, the choice to defer remediation becomes more akin to the choice to defer building in a new feature after the initial release. Meanwhile, security gets the same level of TLC that QA does, resulting in code that actually does deliver security as a subset of quality.
Can Managed Cyber Security Services Help?
At this point you might be wondering what, exactly, it would really take to make a workflow like this into a reality. Sure, an application shielding solution like we described above would be a good start—but if your starting position is a SecOps team that’s working more or less at capacity, installing and maintaining a cyber security solution of any degree of complexity might simply not be in the cards. By the same token, the more you try to integrate SecOps and DevOps in order to merge quality and security, the less attractive pulling security resources off of development and on to IT concerns will seem.
From our perspective, one of the most elegant ways around this problem is to opt for a managed cyber security service. Sure, you might have the in-house capabilities for robust security operations, but is it really in your best interest to devote your security resources to IT maintenance issues like configuring firewalls or managing updates and upgrades to your ecosystem? Wouldn’t it be preferable to let an outside expert manage everything from the installation of the application shielding to threat modeling, monitoring, etc.?
On top of the fact that a managed cyber security service helps you to ensure that you’re not misconfiguring your tools (and thus leaving yourself open to attacks), it can also help you to leverage your resources in the way that makes the most sense for your operations. If your goal is to make cyber security and quality assurance the same thing, managed services can offer you the support you need to make that happen.
Learn More About Intertec’s Managed Cyber Security Services
Intertec provides cutting-edge managed cyber security services based on sophisticated application shielding technology—helping global businesses to cut down on code remediation costs while preventing data breaches. Click here to learn more. Prefer a personal consultation? Go ahead and schedule a meeting with us here!
.png)
