Secure Business Starts with Secure Applications

Applications are the focus of attackers because design flaws create 50% of all exploitable software security opportunities. In fact, over a quarter of all security breaches are caused by just two application code defects – SQL injection and Cross-Site Scripting. Yet only 18% of firms use secure coding standards to reduce their security risk.

Learn how CAST makes you more secure:

Re-Enforce Data Security
Guarantee the security
of your customers’ data.

Conduct Architectural Analysis
Leverage System-Level Analysis to build more secure apps throughout your development cycle.

Build Security In
Ensure your teams are using industry standards, best practices and architectural analysis to build secure applications from the beginning.

Secure the Supply Chain
Ensure your vendors build security
into your apps.

Find What Matters Most
See examples of the types of security vulnerabilities and violations that CAST finds.

Insurance Provider Protects
Client Privacy

How an Insurance firm fixed critical security issues.

Who’s in charge of your data?

One of the key sources of poor data security is a lack of data control. This is an insider threat and an application weakness. Which of your components should directly access the database? Which components actually are? Who’s making sure it’s done right?

Ensuring that your application maintains secure data control procedures requires a system-level understanding of your application to identify which components write to which tables and managing the interaction between them. CAST delivers this system-level understanding of your application to help you take charge of your data.

In the example to the right, CAST shows a database table with numerous objects that directly interact with it. This allows hackers numerous entry points to access the database table and requires each entry point to be evaluated in depth for potential security violations. It also can lead to potential data corruption issues as multiple objects attempt to read and write data simultaneously.


Figure 1: An application with multiple access points for data creates both a security problem (multiple entry points for hackers) AND the potential for data corruption.

What does your architecture say about your application security?


Figure 2: Is this Java method which updates a database table bypassing key business rule validations?

Design flaws account for 50% of security problems! And you can’t find these design flaws by simply staring at your code – you need to know where to look to help you find these ticking time bombs. Architectural risk analysis, performed early in the development cycle, can help you mitigate this risk before it ends up in your application.

Architects can explore their applications looking for compliance with architectural governance standards and ensuring that your design for security initiative is followed. Inspecting the application to define specific rules for your application on how it should interact with the database can help you meet specific regulatory requirements on handling customer data.

Are you following industry standards for secure coding?

Coding standards aren’t just to help you maintain your code. CWE (Common Weakness Enumeration), CISQ (Consortium for IT Software Quality), OMG (Object Management Group), and OWASP (Open Web Application Security Project), all industry standards-setting organizations, have developed a comprehensive set of coding standards for application security. Following these coding standards gives developers clear guidelines in their coding and helps reduce overall application risk.

CAST takes a system-level approach to evaluate code across 9 criteria based directly on these industry standards:

  • Secure Coding - API Abuse
  • Secure Coding – Encapsulation
  • Secure Coding - Input Validation
  • Secure Coding - Time and State
  • Secure Coding - Weak Security Features
  • Efficiency - Memory, Network and Disk Space Management
  • Programming Practices - Error and Exception Handling
  • Architecture - OS and Platform Independence
  • Architecture - Multi-Layers and Data Access

See the full list of CAST’s support for security standards


How secure is the code managed by your vendors?

Vendor contracts should include a service-level agreement (SLA) ensuring that the vendor’s incentives are aligned to protect the organization’s compliance standing and software security posture. This is particularly important when working with cloud computing providers. Often, the procurement or vendor management organization is focused on cost and uptime SLAs, at the exclusion of other nonfunctional software characteristics. Each ADM contract should be reviewed to realign the priorities between client and vendor, providing incentives to address existing software security challenges and deliver new product that’s compatible with the organization’s security policy. In some cases, open source licensing concerns initiate the contract review process. That can open the door for further software security language in the SLA.

Traditional IT security requirements and a simple agreement to allow penetration testing are not sufficient. Having a software measurement capability around security and risk allows the client and vendor teams to set specific, objective, measurable goals.

Are you drowning in false positives?

CAST takes a system-level approach to static analysis that looks at the architectural defects in your application – defects like the potential for SQL injection attacks – to precisely identify where the defect is and how to be remediated. For example:
CWE-89 (SQL Injection) is a weakness where a hacker could include malicious code into a user entry field without validation.

Learn More On System-Level Approach


Figure 3: A username field acting as the entry point for a SQL injection attack.


Figure 4: Where should this transaction data flow be validated? Without seeing the full transaction, you would need to check at each step even if it's validated elsewhere.

In order for the attack to be deterred, at some point in the data flow some validation of the text must be done.

If this validation doesn’t occur, then a security defect exists in the application that can be exploited. BUT, if validation is done elsewhere in the data flow, other tools will report false positives where no defect exists. A system-level approach is required to correctly identify this defect.

CAST identifies this defect correctly and reports it to the developer with the precise location of the defect and how it impacts other objects in the data flow.


Figure 5: CAST shows exactly where the defect is by understanding how each components speaks to each other. This results in a more accurate analysis by finding "hard-to-find" defects and reducing false positives.

How CAST Helped (Insurance Provider Secures Customer Privacy)


Figure 6: Using CAST Health Factors helped this client to identify the applications where they needed to focus attention first and fix critical security defects.

A large health insurance provider had accidentally identified a security vulnerability and was subsequently concerned about what else they weren’t finding.

CAST identified applications at risk of security violations, while CAST’s Security Health Factor helped the team understand which applications to focus their attention and to ensure that they were addressing the right vulnerabilities first.

By identifying these issues early, they were able to remediate these defects quickly, with real insight into the location of specific defects. This enabled the IT security team to focus on the key issues and reduce the risk of the most dangerous security breaches.

Attend A Live Demo

CAST hosts demonstrations of the CAST Application Intelligence Platform and Analytics Dashboard each Tuesday and Thursday. Choose your appropriate schedule and complete the registration form below to join us.

Please Select your Session