Jenkins is a popular tool for managing continuous integration (CI), i.e. coordinating builds, tests and deployment of a software project in an automated way.
In an enterprise context Jenkins has some security requirements, like ensuring that only users with the right permissions can access certain projects and carry out certain tasks, protecting sensitive data such as tokens for access to APIs, etc.
Continue reading →
Continuous Integration or CI is a more and more widely adopted software engineering practice. A best practice for CI is to make the build self-testing, and recently this has started to include security testing. Cryptosense Analyzer, our tool for testing crypto security in applications, now integrates into CI.
This is the third post in a series about cloud crypto functionality provided by the “big three” cloud providers – Amazon Web Services, Microsoft Azure, and Google Cloud Platform (you can find parts one and two here).
Having set up an application and protected its keys with the cloud provider’s crypto API, we’d like to be able to monitor usage of these keys and any key management operations that take place, to be sure all is well and to meet audit requirements. What facilities do the big three providers offer for this?
As usual, the Cryptosense team will be in San Francisco around the RSA conference. We’ll be holding private meetings in a facility 5 minutes walk from the conference venue.
What you’ll get in the meeting: the latest crypto security news, demos of how our software can identify all the crypto in your infrastructure, find and fix vulnerabilities, and help you with secure migration to cloud crypto services.
In a 2014 article “Why does cryptographic software fail?”, Lazar et al. took the most recent 269 CVEs marked as “cryptographic issues” and classified the site of the failure. While 17% of the failures were in crypto libraries, 83% were in the way the applications use the libraries. Up until now, Cryptosense Analyzer for Java applications only treated the 83%. Today that’s changing as we’ve added provider vulnerability testing.
Cryptosense is delighted to announce that we have received funding from BPI France (the Banque Publique d’Investissement) for an exciting new project.
After a competitive selection process, our project was one of 68 selected for funding from a pool of 252 entrants to the 7th edition of BPI France’s Digital Innovation Competition.
This is part two of our series looking at the cloud crypto services offered by the big three hosting companies: Amazon, Google and Microsoft. In part 1, we looked at what kinds of keys and secrets the providers will let you store, and what crypto operations you can do with them. Here, we’re going to look at the way access to keys is controlled for users and services.
With more and more sensitive applications being migrated to the public cloud, we’ve received several requests from our users to help them evaluate how the major cloud providers support crypto and key-management. In a series of posts, we’ll be taking a look at the cloud crypto APIs of AWS, Google, and Microsoft (Azure).
Today Hanno Böck, Juraj Somorovsky and Craig Young announced details of new work testing TLS implementations in the wild for Bleichenbacher’s attack on RSA PKCS#1v1.5 encryption. The short summary is the attack, first made public at CRYPTO ’98, still works on almost 3% of the Alexa top million most visited websites thanks to minor details in the way they implement countermeasures.
Here at Cryptosense we’ve recently been working on adding the last few algorithms to our Java Crypto Analyzer to cover 100% of the standard (SunJCE) provider. The last one we treated was the mysterious-sounding DESede Wrap. What exactly does it do, and is it secure?