As web applications become more widespread and increasingly transactional, more corporate data and business logic are at risk. It has become necessary – in a way it’s never been before – to ensure that every single line does not introduce a vulnerability and that every single software application — whether built for desktop, cloud or mobile — is safe from cyber-attacks and that your intellectual property, customer data (credit card numbers, SSN, addresses, etc.), business processes, and trade secrets are protected.
With so much at risk – money, reputation, legal issues – organizations today agree that web security is a top concern. In some businesses specific regulation exists, like PCI DSS, for payment cards cardholder information handling. This regulation requires compliance to well-defined security standards as an imperative to conducting business.
Security must be accounted for at all layers – from network to application software. It takes a single unsecure pathway to private information to make an entire system vulnerable! The goal, of course, is to eliminate exploitable security risks in software at the application code level and ensure that all pathways to data are secure, and no vulnerabilities would allow a website to be abused for the purposes of spreading malware.
Hackers are known to be ingenious in discovering new entry points along these pathways. They started years ago at the network and hardware levels, but since firewalls and other network devices have closed many gaps, they are now going directly to the application layer.
This means that code security is key to ensuring secure applications, but as everyone in the development space knows, the gulf between development and security is not easily bridged. This is unfortunate as it’s more effective – not to mention cheaper – to solve security problems during the development phase of a project. According to an NIST study, the cost of fixing security issues in software increases substantially further along the Software Development Lifecycle (SDLC) to the point that it costs 30x more to fix security issues after a breach in production than to build security into your code at the beginning of software design.
One way organizations are driving their security efforts is through the use of security testing tools to identify all potentially exploitable vulnerabilities in software at the application code level. Developers and security experts then team up to review these (usually very extensive) vulnerability lists, and fix those that the team agrees should be addressed, according to occurrence frequency, exploit complexity, and potential impact. These reviews require a huge amount of effort – in time, resources, and expertise – and they need to be undertaken every time an organization needs to deploy a new and secure release of an application.
With OutSystems, web security is a bit different. For the past decade, results from every security test – code vulnerability scans, runtime analysis scans, penetration tests – that customers have performed on code generated by our platform have been incorporated back into the platform. That is ten years of accumulated intelligence and improved security. Ten years of security testing … all that knowledge accumulated over the years instantly made available to developers from the moment they begin developing a new application. It’s all in the platform and is an inherent part of every application every customer deploys.
Taking our approach to application security one step further, we’ve recently integrated a security testing tool – HP Fortify Static Code Analyzer – directly into our quality assurance process. By making this security review a part of our product delivery processes, and by enforcing an aggressive acceptance criteria (no critical, no high, no medium reported occurrence left behind) we are able to systematically ensure that the applications generated with the OutSystems Platform – both Java and .NET applications – are inherently secure. When it comes to code vulnerabilities, fix once, fixed forever.
Continuous monitoring and improvement of our platform – along with regular client feedback and regular vulnerability updates from HP – means that application security grows stronger with every iteration.
It’s like having a security expert in-a-box. Even if your developers don’t have the knowledge or the time to properly address code security, your applications are designed and built as if they were developed by security experts. That’s one less NFR (non-functional requirement) you need to worry about.