Test op veiligheid

Veiligheidstesten vinden bugs en problemen voor ze in productie terechtkomen. De verschillende types testen zijn complementair omdat ze elk een ander soort bugs vinden.
De belangrijkste opdeling is tussen automatische tests, zoals statische codeanalyse (SAST) of dynamische applicatietests (DAST), en handmatige testen zoals code reviews en penetratietesten. De eerste soort kan automatisch draaien in de CI/CD pijplijn en vindt vooral de meest voorkomende fouten. De tweede soort is nuttig voor software met een hoog risico.

Automated tests

The most common forms of automated security testing are SAST and DAST. Static code analysis or static application security testing (SAST) analyses the source code with tools for bad coding practices that commonly result in vulnerabilities. Dynamic application security testing (DAST) automatically tests a deployed version of the software against a predefined set of vulnerabilities and exploits. They detect different kinds of bugs and thus should be used together for optimal results.

Automated tests are often integrated in a CI/CD pipeline so as to run automatically on every change of the source code. This prevents many easily detectable but often overlooked bugs from being released in production. The automated nature of this testing makes them very cost-effective and does not have a big impact on the development process.

Hoe wij werken

We will start with a (limited) assessment of your needs in terms of security testing. If we determine your application could benefit from automated testing like SAST or DAST then we will suggest tools or services and how tp integrate them.

We create a list of recommended tools and services to implement automated security testing in your organization or team. The recommendations will be tailored to your specific use of coding languages, frameworks and/or cloud environment.

We can help you with the implementation of the tools and services in your CI/CD pipeline. This is optional and can be performed by your own developers as well, but if you lack the experience is recommended to get everything set up correctly and securely.

Penetration test

A penetration test is an exercise performed for high-risk software that will simulate an actual attack from an adversary. In this exercise, an actual human (or team of humans) will attempt to exploit vulnerabilities in your software and gain access to protected data.

Because of the involvement of a human, a penetration test can find vulnerabilities no automated test can hope to find. It also resembles most closely what a real attacker would do. But this kind of testing comes with a high price, literally. Which is the reason it is often only performed for high-risk software or releases.

Hoe wij werken

We will work together to determine the scope of the penetration test. It will determine what we will test and what the goal of the test is. This can include an entire system, with the goal being to try to penetrate defences and exfiltrate data without being detected. Or it can be much more limited to a single new feature that was added to the software and determine its risk to a Denial of Service (DoS) attack.

Next we will agree on how the test will be performed. Are we allowed access to the source code and documentation of the application (white box testing) or can we only use publicly available information (black box testing). Are we trying to breach the application in a sandbox environment or live on production? Are the IT and development team even aware a test is being performed, or is their response a part of the test? All of these and more will be clearly stated in the Rules of Engagement.

The penetration test itself is performed by trained professionals that will try to breach the defences of your application and reach the goals stated in the initial scope, following the rules of engagement agreed upon.

Results of the penetration test are presented in a comprehensive report. We describe what we did, if we were able to find any vulnerabilities and penetrate your defences, how we did this and how you can solve or mitigate the problems we found.

Code reviews

A code review is a manual assessment of source code meant to increase quality and eliminate bugs. When performed by a developer trained in secure software principles, they can identify and eliminate many security related bugs.

Most companies will want to train their own developers in these secure software principles so they can catch these issues while reviewing the source code of their peers. However, in some instances, where a particularly security sensitive piece of software is being developed, it can be beneficial to let a highly trained security professional perform the code review. Some examples of this type of software are cryptographic algorithms, authentication/authorization protocols and apis, or commonly used security controls.

Hoe wij werken

We will need the functional and non-functional requirements of the software being developed to validate the code that is written meets these requirements.

We will provide your team with a security professional that will review all code created related to the feature that is to be reviewed. The security professional will give feedback directly in your Source Code Manager (SCM). Examples are GitHub, GitLab, Bitbucket or others. Feedback can be an approval or a list of issues, with possible resolutions, that need to be resolved before approval.
Onze missie

Secuma helpt softwarebedrijven om veiligere applicaties te ontwikkelen. We moedigen het gebruik aan en helpen met de integratie van innovatieve oplossingen en processen uit de DevSecOps industrie. Hierdoor verbeteren we de veiligheid van uw applicaties en voorkomen we dat problemen uitgroeien tot incidenten.

Bedrijf

infosecuma.be
Sels Software & Security BV
Hoogputstraat 22B
3690 Zutendaal
België
BE0748911858

Bedankt voor je bezoek aan Secuma |
Afbeeldingen met dank aan Unsplash