Transform your API Management Practice with SOLSYS’ API Strategy Workshop

15 Practices for Shielding Your APIs from Attack: #4 – Tools & Systems

essential startup tools

This post shares experiences from our multi-year journey working with a Canadian client to help them improve their API security and security management. This post discusses the tooling and technology our DevSecOps product development team relies on to make sure the system is kept secure as it is developed. This is a long post, so we start with an overview of the practices to let you jump around if you don’t wish to read the whole post.


The following tools, systems, and platforms are extremely valuable to improving security and ensuring that APIs and the API gateway are protected from falling prey to an attack vector:

code scanning
CI/CD (orchestratable) pipeline tools to automate code and library scanning for security issues, to be used by the DevSecOps product team.
cloud platforms
Specific technologies that help to enable the ‘three Rs’ of security that were discussed in a previous post in this series:

Monitoring tools for synthetic transactions that continuously test positive and negative transactions.
observability and SEIM
Observability and SIEM (Security Event & Incident Management) tools that:

  • Trigger alerts based on transaction information from the monitored platform or product.
  • Provide insight into traffic and patterns.
  • Allow for security event auditing.
code scanning

Code Scanning & Analysis Tools

Security tooling is extremely valuable for DevSecOps product teams in providing information to enable them to make decisions about their implementations.

We use services to scan our 3rd-party libraries and report on things like CVEs that are applicable. There are several types of these tools on the market, and the selection of them would be dependent on language, cost, and licensing choices.

Another type of code scanning tool, an example of which is SonarCube, can perform static analysis on code to identify security exceptions or bad practices. Such tools provide metrics for unit test coverage, code complexity and instances of poor security practices.

Example dashboard from SonarQube showing a scan of a code base with a possible security vulnerability, along with other metrics

As the security owner for their solution, the DevSecOps product team orchestrates these tools as well as evaluates the information they provide. While it can be useful to provide advice and training to the team about their tools, the ultimate decision about the impacts of the analysis metrics, and any resulting code changes, is made by the team since they are the experts closest to the current implementation.

Invoking these tools is usually included as a step in the build (DevOps/CI/CD) pipeline to ensure that reports and measurements are kept up to date. The team can even agree to fail a build if certain thresholds in these metrics are exceeded, which helps the team ensure they’re sticking to their working agreements. This level of automation is something our teams do in the pipeline to ensure security.


Enabling The Three R’s – Cloud Platforms

The three R’s of security – Rotate, Repave, and Repair – are key to the DevSecOps product team and were discussed in our previous post. The ability to execute these ideas, however, is often dependent on tooling. A massive benefit of cloud-based infrastructure, such as AWS or GCP, is that APIs exist to perform these kinds of activities more easily. Cloud Platforms are designed to be easy to orchestrate, configure, and reconfigure. They also provide repositories of updated containers and operating system images since cloud platforms are always virtualized infrastructure.

cloud aws
The ‘big 3’ cloud platform providers all have orchestration APIs for infrastructure, though there are many others available

Enabling the Three R’s – Automation

Our DevSecOps teams use CI/CD pipelines that automatically perform these activities as part of the deployment, grabbing the latest libraries and containers for deployment purposes, and ensuring stateless API services that enable a ‘red green’ style of infrastructure change-over, all with little to no developer intervention at deployment time. In addition to this, our team ensures that credentials and SSL certificates (either internal or for clients) are regularly rotated. Tools like Jenkins and its associated plugins are usually leveraged here as an orchestrator to this pipeline. There are also many other scripting, code, and deployment orchestration languages being called to achieve full automation, however. These can include tools like Chef, Salt, Ansible, Terraform, and Puppet. All of these languages excel at orchestrating software deployment, calling cloud APIs, and configuring systems.

Example pipeline in Jenkins for automated build, test, and deploy, using the BlueOcean plugin
RRR apis

Enabling The Three R’s – APIs

Our API management platform provides services to enable clients to rotate and manage credentials themselves and encourages good security behaviour and practice by making it easy to invoke operations via software. If the tools (in this case APIs) are not available to automate tasks like credential rotation, teams are not likely to find the time to manually invoke the processes required. APIs enabled us to write software to ‘set it and forget it’, which ensures credential security over time.



Automated monitoring tools that deliver synthetic transactions provide another means of ensuring security. By validating connectivity, behaviour, and response times regularly, the DevSecOps team is immediately alerted to possible security compromises triggered by errors in the synthetic transaction. We’ll talk more about the kinds of security vectors these measures help identify and protect against later in the post on specific attack vectors identified by OWASP’s top 10.

observability and SEIM

Observability & SEIM

Observability and SIEM (Security Event & Incident Management) tools play an enormous role in ensuring security. Security breaches happen in the dark when no one is watching, so the best way to improve a system’s security posture is to ensure it is well-observed (see our eBook Convergence Security & Observability for more information!). We make it a core principle for our team to know what’s happening in our product so we can support it. Being a DevSecOps team means that the people building the product also operate and support it – and no one wants to be sitting in the dark when something goes wrong.

Our DevSecOps team iteratively improves logging and observability information produced by the product over time. Enabling a team to make decisions about what kinds of transactions are relevant to report on to improve operations and security, means the experts on the product are always improving their capability to observe more and increase visibility for possible attack vectors.

Observability platforms can be set up to monitor and alert on specific types of events that could indicate a security problem. For us, Splunk provides the observability platform, and our product puts millions of events and tracking records into Splunk daily, to give full insight into the API platform product for our DevSecOps team as well as for external operations and security groups.

Splunk is used with our client as a platform that can provide reporting directly from audit and security logs over 13 months of millions of data events

A DevSecOps team can’t do everything themselves, however. The ability to channel logs into a SEIM platform further enhances security by providing automated use case monitoring of possible attacks. Leveraging machine learning can help to spot aberrant patterns in client behaviour, and highlight possible attacks. Such a platform can check for malicious actors and activity, and alert the team of a possible security gap. This is a great example of a security service that can be deployed by enterprise security to service DevSecOps teams like ours. The product we’ve built already includes well-instrumented and defined access and audit events that track all the information needed to trigger security events, and exemplifies how the product development team can collaborate with the corporate security team to identify attacks and breaches. In the case of the T-Mobile exposure that happened over several weeks, this type of observability and a SEIM platform could have helped them identify the issue sooner.

What’s Next?

In the next few posts, we will start to review some of the OWASP Top 10 attack vectors, and illustrate on a case-by-case basis how the practices discussed so far in this series help to avoid each vector.

Solsys would be pleased to share more details of this experience with you. We have various workshops, such as our API attack vector workshop, and other services available to support you in your API & Software security journey. Please reach out to us by using the contact form on this site to learn how to get started.

Previous/Next Article

Related Resources

What’s your business waiting for?