Contrast, a developer-centric application security company with customers that include Liberty Mutual Insurance, NTT Data, AXA and Bandwidth, today announced the launch of its security observability platform. The idea here is to offer developers a single pane of glass to manage an application’s security across its lifecycle, combined with real-time analysis and reporting, as well as remediation tools.
“Every line of code that’s happening increases the risk to a business if it’s not secure,” said Contrast CEO and chairman Alan Nauman. “We’re focused on securing all that code that businesses are writing for both automation and digital transformation.”
Over the course of the last few years, the well-funded company, which raised a $65 million Series D round last year, launched numerous security tools that cover a wide range of use cases from automated penetration testing to cloud application security and now DevOps — and this new platform is meant to tie them all together.
DevOps, the company argues, is really what necessitates a platform like this, given that developers now push more code into production than ever — and the onus of ensuring that this code is secure is now also often on that.
Traditionally, Nauman argues, security services focused on the code itself and looking at traffic.
“We think at the application layer, the same principles of observability apply that have been used in the IT infrastructure space,” he said. “Specifically, we do instrumentation of the code and we weave security sensors into the code as it’s being developed and are looking for vulnerabilities and observing running code. […] Our view is: the world’s most complex systems are best when instrumented, whether it’s an airplane, a spacecraft, an IT infrastructure. We think the same is true for code. So our breakthrough is applying instrumentation to code and observing for security vulnerabilities.”
With this new platform, Contrast is aggregating information from its existing systems into a single dashboard. And while Contrast observes the code throughout its lifecycle, it also scans for vulnerabilities whenever a developers check code into the CI/CD pipeline, thanks to integrations with most of the standard tools like Jenkins. It’s worth noting that the service also scans for vulnerabilities in open-source libraries. Once deployed, Contrast’s new platform keeps an eye on the data that runs through the various APIs and systems the application connects to and scans for potential security issues there as well.
The platform currently supports all of the large cloud providers like AWS, Azure and Google Cloud, and languages and frameworks like Java, Python, .NET and Ruby.
In the world of software development, one term you’re sure to hear a lot of is full-stack development. Job recruiters are constantly posting open positions for full-stack developers and the industry is abuzz with this in-demand title.
But what does full-stack actually mean?
Simply put, it’s the development on the client-side (front end) and the server-side (back end) of software. Full-stack developers are jacks of all trades as they work with the design aspect of software the client interacts with as well as the coding and structuring of the server end.
In a time when technological requirements are rapidly evolving and companies may not be able to afford a full team of developers, software developers that know both the front end and back end are essential.
In response to the coronavirus pandemic, the ability to do full-stack development can make engineers extremely marketable as companies across all industries migrate their businesses to a virtual world. Those who can quickly develop and deliver software projects thanks to full-stack methods have the best shot to be at the top of a company’s or client’s wish list.
So how can you become a full-stack engineer and what are the expectations? In most working environments, you won’t be expected to have absolute expertise on every single platform or language. However, it will be presumed that you know enough to understand and can solve problems on both ends of software development.
Full-stack is becoming the default way to develop, so much so that some in the software engineering community argue whether or not the term is redundant. As the lines between the front end and back end blur with evolving tech, developers are now being expected to work more frequently on all aspects of the software. However, developers will likely have one specialty where they excel while being good in other areas and a novice at some things….and that’s OK.
Since full-stack developers can communicate with each side of a development team, they’re invaluable to saving time and avoiding confusion on a project.
One common argument against full stack is that, in theory, developers who can do everything may not do one thing at an expert level. But there’s no hard or fast rule saying you can’t be a master at coding and also learn front-end techniques or vice versa.
One hold up you may have before diving into full-stack is you’re also mulling over the option to become a DevOps engineer. There are certainly similarities among both professions, including good salaries and the ultimate goal of producing software as quickly as possible without errors. As with full-stack developers, DevOps engineers are also becoming more in demand because of the flexibility they offer a company.
Founded by longtime developers and Georgia Institute of Technology alumni, Ken Ahrens, Matthew LeRay and Nate Lee had known each other for roughly twenty years before making the jump to working together.
A circuitous path of interconnecting programming jobs in the devops and monitoring space led the three men to realize that there was an opportunity to address one of the main struggles new programmers now face — making sure that updates to api integrations in a containerized programming world don’t wind up breaking apps or services.
“We were helping to solve incident outages and incidents that would cause downtime,” said Lee. “It’s hard to ensure the quality between all of these connection points [between applications]. And these connection points are growing as people add apis and containers. We said, ‘How about we solve this space? How could we preempt all of this and ensure maintaining release velocity with scalable automation?'”
Typically companies release new updates to code in a phased approach or in a test environment to ensure that they’re not going to break anything. Speedscale proposes test automation using real traffic so that developers can accelerate the release time.
“They want to change very frequently,” said Ahrens, speaking about the development life cycle. “Most of the changes are great, but every once in a while they make a change and break part of the system. The state of the art is to wait for it to be broken and get someone to fix it quickly.”
The pitch SpeedScale makes to developers is that its service can give coders the ability to see the problems before the release. They automate the creation of the staging environment, automation suite and orchestration to create that environment.
“One of the big things for me was when I saw the rise of Kubernetes was what’s really happening is that engineering leaders have been able to give more autonomy to developers, but no one has come up with a great way to validate and I really think that Speedscale can solve that problem.”
The Atlanta-based company, which only just graduated from Y Combinator a few months ago, is currently in a closed alpha with select pilot partners, according to LeRay. And the nine month-old company has raised $2.2 million from investors including Sierra Ventures from the Bay Area and Atlanta’s own Tech Square Ventures to grow the business.
“Apis are a huge market,” Ahrens said of the potential opportunity for the company. “there’s 11 million developers who develop against apis… We think the addressable market for us is in the billions.”
ZenHub, the popular project management solution for GitHub users, today announced the launch of its new features for automating hand-offs between teams. The idea behind Automated Workflows, as it is called, is to remove some of the manual busywork of updating multiple boards across teams when a new patch is ready to go to testing, for example (or when it fails those tests and the development team has to fix it).
As ZenHub founder and CEO Aaron Upright told me, Automated Workflows are only the first step in the company’s journey from not just being the most integrated service on GitHub but also the most automated.
Teams still struggle with the mechanics of agile project management, he noted. “Things like what frameworks to choose. How to organize their projects. You talk to small companies and teams, you talk to large companies — it’s a problem for everyone, where people don’t know if they should be Scrum, or Kanban or how to organize Sprint planning meetings.” What ZenHub wants to do is remove as many of these friction points as possible and automate them for teams.
It’s starting with the hand-off between teams because that’s one of the pain points its customers are struggling with all the time. And since teams tend to have their own projects and workspaces, the ZenHub team had to build a solution that worked across a company’s various boards.
The result is a new tool that is pretty much a drag-and-drop service that automatically creates notifications and moves items between workplaces as they move from QA to production, for example.
“It’s a way to automate work between different workspaces,” explained Upright. “And we’re really excited about this being kind of the first step in our automation journey.”
Over time, Upright expects, the team will be able to use machine learning to understand more about the connections that its users are making between teams. Using that data, its systems may be able to also recommend workflows as well.
The next part of ZenHub’s focus on automation will be a tool for managing the Sprint planning process.
“Already today’s, ZenHub is capturing things like velocity. We’re measuring that on a team by team basis. We understand the priority of issues in our workflow. What we want to be able to do is allow teams to automatically set a Sprint schedule, say, for example, every two weeks. Then, based on the velocity that we know about your team, maybe your team can accomplish 50 story points every two weeks — we want to auto-build that Sprint for you.”