What do SAST, DAST, IAST and RASP Mean to Developers?

security best practices


It’s estimated that 90 percent of security incidents result from attackers exploiting known software bugs. Needless to say, squashing those bugs in the development phase of software could reduce the information security risks facing many organizations today. To do that, a number of technologies are available to help developers catch security flaws before they’re baked into a final software release. They include SAST, DAST, IAST, and RASP.

Join Our DevSec Friday Community!

Free security workshops every Friday @ 12pm EST.

Learn more about integrating SAST and DAST tools into your pipeline with our 600+ developers and security professionals.


SAST, or Static Application Security Testing, also known as “white box testing” has been around for more than a decade. It allows developers to find security vulnerabilities in the application source code earlier in the software development life cycle. It also ensures conformance to coding guidelines and standards without actually executing the underlying code.

DAST, or Dynamic Application Security Testing, also known as “black box” testing, can find security vulnerabilities and weaknesses in a running application, typically web apps. It does that by employing fault injection techniques on an app, such as feeding malicious data to the software, to identify common security vulnerabilities, such as SQL injection and cross-­site scripting. DAST can also cast a spotlight in runtime problems that can’t be identified by static analysis­­ for example, authentication and server configuration issues, as well as flaws visible only when a known user logs in.

SAST & DAST Are Usually Used in Tandem

SAST and DAST are often used in tandem because SAST isn’t going to find runtime errors and DAST isn’t going to flag coding errors, at least not down to the code line number. SAST performs well when it comes to finding an error in a line of code, such as weak random number generation, but usually not very efficient in finding data flow flaws. In addition, SAST solutions are notorious for the larger amount of false positive or false negatives. We created reshift, a free static security testing tool that uses our proprietary machine learning algorithm to triage false positives faster, check it out here if you are interested.

Abstract Interpretation: Some success in reducing or entirely eliminating false positives has been achieved with something called Abstract Interpretation. However, to get the best results, abstract interpretation algorithms need to be tailored to codes using an application’s domain, which includes its architecture, how it uses certain numerical algorithms and the types of data structures it manipulates.


Despite SAST’s imperfections, it remains a favorite among development teams. They like that it allows them to scan a project at the code level, which makes it easier for individual team members to make the changes recommended by the technology. it also lets them find flaws early in the development process, which helps reduce the costs and ripple effects that result from addressing problems at the end of the process.

What’s more, SAST can be automated and transparently integrated into a project’s workflow. That removes some of the hassle typically associated with testing apps for security and contrasts sharply with DAST where, for large projects, a special infrastructure needs to be created, special tests performed and multiple instances of an application run in parallel with different input data.

DAST, though, understands arguments and function calls so it can determine if a call is behaving as it should be. SAST can’t check calls and in most cases, is unable to check argument values.

Interactive Application Security Testing (IAST)

IAST or Interactive Application Security Testing. Because both SAST and DAST are older technologies, there are those who argue they lack what it takes to secure modern web and mobile apps. For example, SAST has a difficult time dealing with libraries and frameworks found in modern apps. That’s because static tools only see the application source code they can follow. What’s more, libraries and third­party components often cause static tools to choke, producing “lost sources” and “lost sinks” messages. The same is true for frameworks. Run a static tool on an API, web service or REST endpoint, and it won’t find anything wrong in them because it can’t understand the framework.

IAST is designed to address the shortcomings of SAST and DAST by combining elements of both approaches. IAST places an agent within an application and performs all its analysis in the app in real-time and anywhere in the development process ­­ IDE, continuous integrated environment, QA or even in production.

Because the IAST agent is working inside the app, it can apply its analysis to the entire app ­­ all its code; its runtime control and data flow information; its configuration information; HTTP requests and responses; libraries, frameworks and other components; and backend connection information. Access to all that information allows the IAST engine to cover more code, produce more accurate results and verify a broader range of security rules than either SAST or DAST.

Run-time Application Security Protection (RASP)

RASP, or Run-time Application Security Protection As with IAST, RASP, or Run­time Application Security Protection, works inside the application, but it is less a testing tool and more a security tool. It’s plugged into an application or its run­time environment and can control application execution. That allows RASP to protect the app even if a network’s perimeter defenses are breached and the apps contain security vulnerabilities missed by the development team. RASP lets an app run continuous security checks on itself and respond to live attacks by terminating an attacker’s session and alerting defenders to the attack.

An issue particular to RASP is it can create a sense of false security within a development team. They may not adhere to security best practices thinking, “If we miss something, RASP will pick it up.”

The problem with technologies like IAST and RASP is they can have an adverse effect on application performance, although boosters of the tech any performance hits are minimal. An issue particular to RASP is it can create a sense of false security within a development team. They may not adhere to security best practices thinking, “If we miss something, RASP will pick it up.” But even if RASP finds a flaw, the development team still has to fix the problem and while they do, the application may have to be taken offline, costing an organization time, money and customer goodwill.

Regardless of the challenges found in technologies like SAST, DAST, IAST and RASP, using them can create software that’s more secure and do it in a way that’s faster and more cost ­effective than tacking all security testing to the tail of the development process.

Want to test your code now?

Connect with Github, Bitbucket, or Gitlab and generate vulnerability reports for your projects.

Was this article helpful?

Comparing the Top 3 Federated Indentity Providers: OpenID, OAuth, SAML

For an updated version of this article please click here.

What is Federated Identity?

Federated identity means linking and using the electronic identities a user has across several identity management systems.

In simpler terms, an application does not necessarily need to obtain and store users’ credentials in order to authenticate them. Instead, the application can use an identity management system that is already storing a user’s electronic identity to authenticate the user—given, of course, that the application trusts that identity management system.

This approach allows the decoupling of the authentication and authorization functions. It also makes it easier to centralize these two functions in the enterprise to avoid a situation where every application has to manage a set of credentials for every user. It is also very convenient for users, since they don’t have to keep a set of usernames and passwords for every single application that they use.

Some Background Information

Single sign-on (SSO) started it all. Organizations needed a way to unify authentication systems in the enterprise for better management and security. Single sign-on was widely adopted and provided a solution for keeping one repository of usernames and passwords that could be used transparently across several internal applications.

Service-oriented software kicked off the next wave of change. Organizations wanted to open APIs in their software so partners and independent developers could use them. Managing authentication and authorization for entities looking to consume these APIs was obviously a challenge.

Social media moved things even further. Various platforms spread far and wide on a plethora of devices, and many applications were built on top of those platforms. Now we have countless apps and services hooked into Twitter, Facebook, and LinkedIn.

The problem? How to bring together user login information across many applications and platforms to simplify sign-on and increase security. The solution? Federated identities …

There are three major protocols for federated identity: OpenID, SAML, and OAuth.


OpenID is an open standard sponsored by Facebook, Microsoft, Google, PayPal, Ping Identity, Symantec, and Yahoo. OpenID allows user to be authenticated using a third-party services called identity providers. Users can choose to use their preferred OpenID providers to log in to websites that accept the OpenID authentication scheme.

The OpenID specification defines three roles:

  • The end user or the entity that is looking to verify its identity
  • The relying party (RP), which is the entity looking to verify the identity of the end user
  • The OpenID provider (OP), which is the entity that registers the OpenID URL and can verify the end user’s identity

The following diagram explains a use case for an OpenID scenario:

federated identity_OpenID

Security Considerations

OpenID had a few interesting vulnerabilities in the past, for example:

  • Phishing Attacks: Since the relying party controls the authentication process (if necessary) to the OpenID provider, it is possible for a rogue relying party to forward the user to a bogus OpenID provider and collects the user’s credentials for the legal OpenID provider.
  • Authentication Flaws: In March 2012, three researchers presented a paper that highlighted two vulnerabilities in OpenID. Both vulnerabilities allow an attacker to impersonate any user to a website if the website doesn’t properly check whether the response from the OpenID provider contains a properly signed email address.


Security Assertion Markup Language (SAML) is a product of the OASIS Security Services Technical Committee. Dating from 2001, SAML is an XML-based open standard for exchanging authentication and authorization data between parties.

The SAML specification defines three roles:

  • The principal, which is typically the user looking to verify his or her identity
  • The identity provider (idP), which is the entity  that is capable of verifying the identity of the end user
  • The service provider (SP), which is the entity looking to use the identity provider to verify the identity of the end user

The following diagram explains a use case for a SAML scenario:

federated identity_SAML

Security Considerations


OAuth is another open standard. Dating back to 2006, OAuth is different than OpenID and SAML in being exclusively for authorization purposes and not for authentication purposes.

The OAuth specifications define the following roles:

  • The end user or the entity that owns the resource in question
  • The resource server (OAuth Provider), which is the entity hosting the resource
  • The client (OAuth Consumer), which is the entity that is looking to consume the resource after getting authorization from the client

The following diagram explains a user case for an OAuth scenario:

Security Considerations

  • A session fixation vulnerability flaw was found in OAuth 1.0. An attacker can fix a token for the victim that gets authorized. The attacker then uses the fixated token.
  • OAuth 2.0 was described as an inherently insecure protocol since it does not support signature, encryption, channel binding, or client verification. The protocol relies entirely on the underlying transport layer security (for example, SSL/TLS) to provide confidentiality and integrity.

This table explains the major differences between the three protocols:





Dates From




Current version

OpenID 2.0

OAuth 2.0

SAML 2.0

Main Purpose

Single Sign-On for Consumers

API Authorization Between Applications

Single Sign-On for Enterprise Users

Protocols Used




No. of Related CVEs




Other Protocols

There is a growing number of other federated identity options. Here are a few examples.

Higgins: Higgins is a new open source protocol that allows users to control which identity information is released to an enterprise.

Windows CardSpace: CardSpace is Microsoft new identity metasystem that provides interoperability between identity providers and relying parties with the user in control. This protocol is retired though and Microsoft is working on a replacement called U-Prove.

MicroID: MicroID is a new identity layer to the web and microformats that allow anyone to simply claim verifiable ownership over their own pages and content hosted anywhere.

Liberty Alliance: Liberty Alliance is a large commercially oriented protocol providing inter-enterprise identity trust. It is the largest existing identity trust protocol deployed around the world.

Here is a quick summary of federated identities. 

Stop shipping vulnerable code.


In a world with increased interconnectivity between hybrid systems, protocols, and devices, federated identity seems to be here to stay. Although federated identity is much more convenient for users who don’t have to remember so many different usernames and passwords, it comes with a security price. However, proper implementation of OAuth, SAML, OpenID, or any other federated identity protocol adds convenience without extra threat surface.

For an updated article comparing OpenID Connect vs SAML 2.0 vs OAuth 2.0, please click here.

Was this article helpful?

Our Security Assessment Process: Attack Simulation Approach

Attack Simulation Approach

The term security assessment is used to describe the process of auditing a system, such as a network or an application, for the purpose of finding security flaws that can lead to cyber attacks. There are several ways that to perform security assessments for a system.

At Software Secured, we follow an attack simulated approach, combining the latest hacking techniques, which are manually executed by our experienced engineers. In addition, we apply our unique process, checklists and hacking book, giving you the best coverage and depth in the industry.

We focus on optimizing on 3 factors:

1. Coverage: we use several techniques to automate the discovery of basic attacks. We continue pushing the boundaries of what tools are capable of finding,  giving us the chance to spend more manual testing time on finding harder to discover vulnerabilities, such as business logic vulnerabilities.

2. Depth: we follow a stringent process, combined with a checklist of 120+ security items that are reviewed in every assessment. Our checklist is continuously updated with the most recent techniques to ensure that as many code paths in the application have been tested.

3. Attack Simulation: we spend a fair amount of time understanding the business purpose of the application allowing us to go deeper and understand the attacker’s motivation. This uncovers potential vulnerabilities that are usually hidden.

Given our 3 areas of focus, we follow a 6 step process with every assessment:

1. Kickoff Meeting

We begin with a kickoff meeting with the client to understand the business purpose of the application, this helps us better understand who is most likely to attack the application.

2. Threat Modelling Exercise

A threat modelling exercise is performed next. Threat modelling breaks down the system and outlines how and where the attacker can pose a threat. The artifact of this step is a set of application specific test cases and attacks that are unique for the system under test.

3. Automation

We use best in class tools customized to fit the attack simulation process, combined with our proprietary tools and scripts to provide you with a more thorough assessment.

4. Attack simulation

Our security engineers apply their collective hacking experience combined with latest attack techniques to simulate what an attacker would do in a real life hacking scenario.

5. Coverage Control

Using our checklist which consists of over 120+ security checklist items, helps to ensure all bases are covered. This ensures that most of the application’s code paths are tested and maximum coverage is maintained for every assessment.

6. Reporting

finally, our team compiles the list of issues into an actionable report. Each issue is explained in detail along with the risk level associated with it, steps to reproduce, proof of concept, and detailed remediation steps.

Our attack simulated approach to security assessment can be delivered as a one-off engagement or continuously managed.