loading...
Cover image for Automated Software Security Testing for Devs—Part 1

Automated Software Security Testing for Devs—Part 1

cossacklabs profile image Cossack Labs Updated on ・4 min read

Automated Software Security Testing for Developers (4 Part Series)

1) Automated Software Security Testing for Devs—Part 1 2) Automated Software Security Testing for Devs—Part 2 3) Automated Software Security Testing for Devs—Part 3 4) Automated Software Security Testing for Devs—Part 4

Delve into ways and tools of software security testing that developers can set up and automate to make their apps more secure 🔐


At Cossack Labs, we build data security and encryption software. Taking care of mitigating threat vectors for our customers, we can not give any chance for weaknesses in our software. That's why, over the years, we elaborated an arsenal of approaches to find and prevent defects early in the security software development process. In this series, we share what to look at, how to spend effort and “shift security left”, and which tools to use.


Part 1


💡 Merits of continuous security testing

To begin, software security tests are just like any other kinds of tests—except that most of them don’t verify predefined behaviour. Instead, they check for the absence of certain behaviours and weaknesses known to lead to some security risks.

Many known security issues arise from undetected software behaviour that doesn’t visibly break the main functionality of the software. Such bugs are of the most cunning kind because everything seems to be working as intended.

Separate testing ensures that new commits and builds don’t introduce security problems, and it is an essential practice to be applied to software with high demands to security.

As a part of the continuous integration (CI) and running tests repeatedly, security tests allow to identify and fix such issues as memory bugs, input bugs, performance-hindering issues, insecure behaviour, and undefined behaviour.

Nevertheless, before the rise of continuous integration, writing and implementing such tests wasn’t everyone’s idea of a great resource allocation even within the security engineering community (although manual security check is an example of even worse time expenditure).

These days, when security-related scares and threats arise repeatedly, writing security tests should become everyone’s favourite hobby because every piece of software contributes to the overall security or the lack thereof.

💡Getting started

A good place to start with security testing is to find out what security controls are actually present in your product (application, website, etc.), like input sanitization, buffer overflow prevention, protection from SQL injection, XSS prevention, authorization enforcement, triggering security events.

The next step is gaining an understanding of how these controls are affected by execution flow and input data, whether it can be altered, or is it possible for the expected behaviour to fail unexpectedly.

📎To ensure the software product is safe from most vulnerabilities, security testing process could include several takes. For example:

  • Functional security tests verify that security controls of your software work as expected.
  • Non-functional tests look for known weaknesses and faulty component configurations (i.e. usage of crypto that is known to be weak, source code analysis for memory leaks, and undefined behaviour, etc.).
  • Holistic security scans for vulnerabilities across the entire attack surface, when an app or infrastructure are tested as a whole by offensive security testers.
  • Manual testing and code review are used when there is a need for sophisticated work that still cannot be quite algorithmized and requires human attention.

Slide from @vixentael talk about maintaining cryptographic library Themis and testing layers

⇪⇪⇪ Slide from @vixentael talk about maintaining cryptographic library Themis and testing layers.

💡Testing security controls/DAST

Testing security controls and security components boils down to making sure that security controls behave as expected under chosen circumstances.

Examples include active/passive attacks on API calls wrapped in HTTPS, passing SQL injection patterns into user input, manipulating parameters to mount path traversal attacks, etc. The goal of a dynamic application security testing (DAST) is to emulate attacks and identify potential vulnerabilities, treating system as a whole.

📎You could go with DAST with the following open-source tools:

⚙️ OWASP Zap and OWASP Zapper (Jenkins plugin). They allow automating attack proxy to test some of the possible attacks,
⚙️ BDD-security suite is used as a testing framework for functional security testing, infrastructure security testing, and application security testing,
⚙️ Gauntlt which is a number of Ruby hooks to security tools to integrate into your CI infrastructure,
⚙️ Mittn, F-Secure’s security testing tools for CI, originally inspired by Gauntlt.

While these tools are not a substitute for careful inspection by a security professional, at least they ensure a certain level of formalizable verification for security controls.

Upon verifying that security controls of your application are working properly, it’s time to extend the testing efforts to code checking, fuzzing, dependency scanning and other causes of security errors.


☛ Follow the series to get into other aspects.

Automated Software Security Testing for Developers (4 Part Series)

1) Automated Software Security Testing for Devs—Part 1 2) Automated Software Security Testing for Devs—Part 2 3) Automated Software Security Testing for Devs—Part 3 4) Automated Software Security Testing for Devs—Part 4

Posted on by:

cossacklabs profile

Cossack Labs

@cossacklabs

Data security & cryptography. Focus on business growth—while we take care of sensitive data risks, security engineering challenges & compliance requirements

Discussion

markdown guide