devopsy.kinsta.cloud

Category: DevOps Practice

4 Reasons Software Developers Need a Bill of Materials
The recent Log4j/Log4Shell vulnerability was a wake-up call that threats aren’t going to wait until the industry gets up to speed on software supply chain security. While the Log4j open source component vulnerability caught us all off guard, it did highlight the need for software vendors to be more proactive in disclosing the composition of their products. It’s become painfully clear that analyzing open source libraries and third-party code should become standard practice to understand their makeup and the potential risks they introduce in commercial software applications.

Unfortunately, relying on open source projects to provide visibility into security vulnerabilities isn’t going to work. In most cases, these projects are grossly underfunded. At the time of the Heartbleed vulnerability, for example, OpenSSL received very little funding. Yet, open source usage increases each year. It’s imperative that commercial software organizations contribute to open source projects they use and share responsibility for the security of these products.

In addition to open source libraries, most vendors source third-party code from contractors or for-hire development organizations. Without documentation of the composition of the code developed by third parties, it’s impossible for commercial software vendors to proactively identify and manage risk before it’s implemented in their development cycle.

Using Software Composition Analysis (SCA) Tools

Where a software bill of materials (SBOM) is not provided, the onus should be on commercial software vendors to create one. This can be accomplished using software composition analysis (SCA) tools that analyze binaries and do not require access to source code. They can generate SBOMs to identify open source or third-party components in use, as well as track and manage security risks in the software supply chain.

Creating a comprehensive SBOM provides other benefits, since most open-source projects and contract developers are only likely to publish direct dependencies (if at all) and not look further into the dependencies of dependencies, and so on.

Four Benefits to Consider

Meanwhile, commercial software vendors can expect their customers to soon start demanding SBOMs since this will be a requirement under the cybersecurity executive order. Given this evolving landscape, commercial software vendors should consider the following four benefits for proactively implementing an SBOM program to govern the products they build:
- Gain visibility into software supply chain risk to identify, reduce and remove vulnerabilities in reused software (i.e. open source and third-party). SBOMs provide data for business decisions on the software you have reused and purchased. It’s better to discover these risks before your customers do.
- Preemptive supply chain qualification to ensure compliance with future requirements. SBOMs will soon be a requirement for doing business with the U.S. federal government. Suppliers that meet the SBOM requirements during procurement will be given preferential treatment.
- Improved security and downstream benefits that come with risk management and mitigation. Avoiding, detecting and remediating security risks before they become embedded in a product pays huge dividends during development and deployment. You’ll be better prepared for the next security event.
- Common understanding of software assets that comes with a standardized SBOM shared amongst developers, suppliers and open source projects. An SBOM becomes a way to communicate software contents and dependencies within and outside an organization.
Taking a proactive approach to the software supply chain by creating SBOMs and demanding the same from suppliers will enable commercial developers to be better prepared for the next Log4j/Log4Shell vulnerability. It will also allow them to improve the software supply chain security posture of their end customers.
March 3, 2022
Tabnine, GitLab Build Custom Apps Faster With AI

Tabnine today revealed it has integrated its code completion tool with the GitLab continuous integration/continuous delivery (CI/CD) platform. Tabnine’s platform employs artificial intelligence (AI) to accelerate application development.

Brandon Jung, vice president of ecosystems and business development at Tabnine, said the goal is to make it easier for developers to automatically write code based on custom models created using AI. Those models would reside in the CI/CD platform provided by GitLab. Developers can now create custom models of their private source code, he noted.

The Tabnine AI assistant can then be trained on a customer’s private code, style and security best practices that have been defined by an internal DevOps team, added Jung. That assistant, accessible from within a developer’s integrated development environment (IDE), is conversant in 35 programming languages.

The code completion tool doesn’t eliminate the need for developers to write code; instead, it completes code once developers start writing it based on the model stored in the CI/CD platform.

Nima Badiey, vice president of global alliances for GitLab, said the overall goal is to increase developer productivity at a time when organizations are launching more application development initiatives than ever. Many of those applications are being constructed using multiple programming languages that each individual developer may not have equally mastered.

In addition, an AI model will, over time, improve the quality of the code being created, noted Badiey. That should make it easier to review code that is more accurate because it was created with the aid of a machine, he added.

In general, GitLab has been moving to incorporate AI within DevOps workflows. The company last year acquired UnReview, a provider of a tool that uses machine learning algorithms to identify which code reviewers to assign to a project based on both the quality of their previous efforts and their current workloads.

It’s not clear to what degree AI will be pervasively embedded within DevOps workflows. However, it’s now just a matter of time before algorithms are more widely employed. Organizations that employ DevOps today devote significant resources to maintaining platforms that could be simpler to manage if more tasks and processes were automated. In theory, more resources could be then devoted to building applications versus maintaining DevOps platforms.

One way or another, more organizations are moving to increase developer productivity. Developers are both hard to find and retain, so organizations have a vested interest in finding ways to increase the rate at which an existing pool of developers can build applications capable of driving a wider range of digital business transformation initiatives. Of course, an increase in the rate at which applications are developed also has significant implications for the rate at which they might need to be deployed.

Not everyone in IT is, of course, entirely comfortable with AI. Nevertheless, most DevOps organizations are highly committed to automating as many processes as possible. The only thing that will be different going forward is determining to what degree those processes will be automated by humans versus a machine.

March 2, 2022
Linux Foundation Lists Top Open Source Libraries

The Linux Foundation today published a report that provides access to eight lists of the top 500 open source libraries being used by organizations as part of an ongoing effort to help better secure software supply chains.

The Census II of Free and Open Source Software—Application Libraries report is based on usage data from providers of software composition analysis (SCA) tools such as Snyk, the Synopsys Cybersecurity Research Center (CyRC) and FOSSA. The report itself was compiled by the Harvard Lab for Innovation Science.

The eight lists are made up of four that include version numbers and four that are version agnostic. The lists are separated into npm and non-npm packages because npm packages would dominate any ranking created. The top non-npm packages being employed include maven, nugget, Go and cargo.

Frank Nagle, assistant professor at Harvard Business School, said the report is intended to provide organizations with some guidance in terms of knowing what open source packages are used in the wake of recent vulnerabilities discovered in the widely employed Log4j software used to manage logs within Java applications.

Many of the organizations impacted by that vulnerability were unaware of just how widely deployed Log4j was within their enterprise IT organizations. IT organizations should evaluate the sustainability of those projects in terms of the number of contributors and maintainers that are working to ensure the security of those libraries.

One of the biggest challenges is to find a way to standardize naming schema for software components and the overall management of versions of different libraries, noted Nagle.

Ultimately, the goal is to convince more enterprise IT organizations—and the vendors that support them—to make more resources available to secure those libraries, noted Nagle. Much of the most widely used open source software is developed and maintained by only a handful of contributors. Many of those contributors argue that, while they made that software available for free, it is the responsibility of the organizations employing it to secure it.

The Linux Foundation is moving to become a conduit through which it will make available additional resources to help better secure open source software. The Open Source Security Foundation (OpenSSF), a consortium hosted at the Linux Foundation, earlier this week announced that 19 additional organizations have joined OpenSSF to help identify and fix security vulnerabilities in open source software and improve tooling, training, research, best practices and vulnerability disclosure practices.

Brian Behlendorf, executive director at OpenSSF, said in addition to making resources available, it’s clear there is a need for some form of a third-party audit of open source software as organizations are more broadly employing that software across their software supply chains.

New premier member commitments to OpenSSF are now coming from 1Password, Citi, Coinbase, Huawei Technologies, JFrog and Wipro. New general member commitments are being made by Accuknox, Alibaba Cloud, Block, Inc., Blockchain Technology Partners, Catena Cyber, Chainguard, DeployHub, Gravitational Inc., MongoDB, NCC Group, ReversingLabs, Spotify and Wingtecher Technology. New associate members include Institute of Software, the Chinese Academy of Science (ISCAS), MITRE and OpenUK.

Other efforts led by the OpenSSF include an Alpha-Omega Project to better secure open source security posture, scorecards that identify risks of the dependencies within more than one million projects, multi-factor authentication tokens and a Project Sigstore initiative to sign, verify and protect open source code.

It may be a while before open source software achieves the level of security the IT industry strives for. On the plus side, however, there have never been more resources allocated to achieving that goal.

March 2, 2022
Ukraine Asks for DNS Censorship | Ukraine Snapchat Staff Danger | #BoycottKaspersky?

Welcome to Ukraine Week here at The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: Censoring the Russian internet, Snap fears for hundreds of Ukrainian employees, and Eugene Kaspersky acts like a ****.

1. ICANN, but IWONT

First up this week: Ukraine has asked ICANN to drop Russia from the DNS. Andrii Nabok, the Ukrainian representative of ICANN’s Governmental Advisory Committee argues a DNS blockage would “help users seek for reliable information in alternative domain zones, preventing propaganda and disinformation.”

Given today’s confirmation that Muscovite K12 students had been arrested for laying flowers at the Ukrainian embassy, this goal seems all the more laudable. But frankly, a moment’s thought says it’s a bad idea.

Analysis: “The net interprets censorship as damage and routes around it”

John Gilmore was right. Such a move would inevitably fail. And there’s a real risk of undesirable, unintended consequences.

Kat Bouza and Noah Shachtman: Ukraine Pushes to Unplug Russia From the Internet

Ukraine’s request to the Internet Corporation for Assigned Names and Numbers (ICANN) seeks to revoke domains issued in Russia and shut down primary Domain Name System (DNS) servers in the country. [It] would send a strong message to a regime pumping out digital propaganda.
…
The DNS root zone is a crucial element of the overall functionality of the internet, responsible for handling queries to top-level domains — such as .com, and country-specific domains like Russia’s .ru. Removing Russia’s access to this cluster of servers would prevent Russian internet-service providers from communicating.
…
But … the unprecedented request has the potential to do more harm than good. … Representatives for ICANN … declined to comment.

But the request is pretty naïve, thinks this Anonymous Coward:

All they would have to do is get the ISPs to add a zone to their DNS that says “ru. IN NS x.x.x.x” and then for all their users, any requests for a .ru domain would be directed to x.x.x.x

OK, the rest of the world would miss out, but I doubt that they would care.

Is there a better way? ArmoredDragon breathes fire:

A better way … is to ask western certificate authorities to revoke all [Russian] certificates. Then ask the major OS and browser vendors to remove any CAs that don’t comply.

That would really **** with them because there’s nothing [Russia] can do about that. And it would even **** with Russia’s ability to do business with Chinese companies and Chinese customers.

2. Fear for 300 Ukraine Employees at Snap

Snap, Inc.—formerly Snapchat—owns the Ukrainian company that created the technology used in the real-time video shenanigans behind “I’m not a cat.” It has hundreds of employees in Kyiv and Odesa.

Analysis: Solidarity doesn’t Stop Wars, but Sanctions Might

This very human DevOps story is but a footnote to the wider picture of tech companies acting to echo Western governments’ sanctions. It’ll cause us a little pain, but that’s nothing compared to the suffering felt by Ukrainians. And it’ll be worthwhile if it shortens the war.

J. Clara Chan: Three hundred Snap employees are from Ukraine

In a public note, … Snap — the parent company of Snapchat — said … that 300 of Snap’s “most creative and talented team members” are from Ukraine, … the birthplace of Looksery, the augmented reality platform that Snap acquired in 2015. … Snap said it has pledged over $15 million in humanitarian aid to support Ukraine. … The company is also providing emergency assistance to employees who need help safely relocating.
…
“We stand in solidarity with our Ukrainian team members and the people of Ukraine. … This is a devastating conflict with far-reaching consequences. … It is a direct threat to many of our team members and their families.
…
“Over many years working with our Ukrainian colleagues and friends, we have gotten to know the inventiveness, strength, and resilience of the Ukrainian people. … We will continue to work tirelessly to help our Ukrainian team members and their families, support our Snapchat community, and determine how we can help make positive contributions to the immense humanitarian efforts underway.”

It’s bang on trend, reports Corinne Reichert:

Snapchat has followed suit after Facebook, Twitter and YouTube began pausing ads on Friday, saying it has now stopped all advertising running in Russia, Ukraine and Belarus following the Russian invasion of Ukraine. … The Snapchat app remains live in Ukraine, Russia and Belarus, [but] Snap is monitoring the platform for misinformation or other misuse.
…
Apple has also halted sales of its products in Russia, as well as online transactions, Apple Pay and some Apple Maps features. Google [is] temporarily disabling some live Google Maps features, adding an SOS alert to Search and blocking Russian state-controlled media. It said Google Pay “may become unavailable.”

But don’t hang up on Dade “+++ATH” Hayes: [ask your parents]

In terms of any financial sacrifice from the foregone advertising opportunities, it isn’t clear that all that much is at stake for Snap. … While the company’s stance on the Russia-Ukraine situation clear and emphatic, it is also an easier one for for Snap to take than for many of its tech rivals.

3. Yevgeny Valentinovich ‘Eugene’ Kaspersky has Chosen the Side of the Oppressor

The figurehead eponym of AO Kaspersky Lab is being publicly shamed for comments he made about the war in Ukraine. In stark contrast to Snap’s statement, he is accused of overt neutrality, minimizing the war’s severity—and even of shoehorning in some marketing.

Analysis: #BoycottKaspersky

Desmond Tutu was right. But, while it’s tempting to “cancel” Eugene, dial down the emotion and think instead about your security posture. If you use Kaspersky products internally, what risks are you exposing your organization to? How might the Russian government exert pressure on the company to compromise your network?

James Coker: Eugene Kaspersky’s Statement Provokes Controversy

Cybersecurity industry veteran Eugene Kaspersky has provoked a strong reaction from leading figures in the sector. … Kaspersky, CEO of the Russian-headquartered IT security vendor of the same name, broke his silence on the conflict:
…
“We welcome the start of negotiations to resolve the current situation in Ukraine and hope that they will lead to a cessation of hostilities and a compromise. We believe that peaceful dialogue is the only possible instrument for resolving conflicts. War isn’t good for anyone. … The main thing we can do in this situation is provide uninterrupted functioning of our products and services.”
…
His description of the conflict as a “situation” and apparent attempt to advertise his firm led to a number of furious responses. … Following Kaspersky’s tweet, the hashtag #BoycottKaspersky appeared.

With a balanced view, it’s Nick Farrell:

Kaspersky sits on the fence … in Russia it is not a good idea to have a view. [But] whoever is advising Kaspersky on PR might need to have a rethink.
…
After all a compromise is [not] always possible when one side is firing missiles into residential areas. If he applied the same premise with ransomware, he would be suggesting, … “It is better that you talk to the people who are holding your servers hostage.” … How much is Kaspersky, the company, influenced by the Russian government?

Does your shop use Kaspersky? Nick Lange cuts to the chase:

I would like to remind all readers that, in case of war, … software with access to companies and the capacity to be updated worldwide in matter of hours at the same time is a high class target to get forced to cooperate by a autocratic government.

The Moral of the Story: If an elephant has its foot on the tail of a mouse and you say that you are neutral, the mouse will not appreciate your neutrality.

You have been reading The Long View by Richi Jennings. You can contact him at @RiCHi or tlv@richi.uk.

Image: Brandon Morales (via Unsplash; leveled and cropped)

March 2, 2022
Where Has All the Testing Gone?

Testing has long been a problem child of IT in general, AppDev in particular, and now it is DevOps’ problem. There are things that DevOps can do to improve the chances of tests actually occurring for your application(s). Interestingly, there are some that think we no longer need testing; the argument is that because new releases can be cranked out so quickly if something needs to be fixed that it is irrelevant. Combining feature flags with the ability to roll out a new version and, well, there may be some truth to that—at least for a limited subset of testing.

If an organization implemented feature flags for user acceptance and new feature testing and then standardized on test-driven development for DevOps development teams, that would leave systems and security testing. Systems testing could, theoretically, be replaced by the ability to roll out a new version. Although systemic issues can be complex and difficult to fix, this is a riskier proposition than extending test-driven development to the systems level. For the sprint, assign a person responsible for the overall integrated system and have the rest of the team support them through the process of making certain all works as expected.

Testing—particularly systems testing—slows releases. I get that. The rate at which most of us can iterate once DevOps systems and processes are in place is fast enough that you can afford a bit of slowdown. This leaves security testing as the last standalone bit. But some security validation can happen during the development process if DevSecOps tools are being utilized. That still leaves some security issues to test for but does remove a large chunk.

The key to these last bits is to get them integrated into the process/toolchain. DevOps runs straight through, over and over. Any bit worked into the “runs straight through” will be executed. If today’s iteration falls for the “We ran over, we’ll make the deadline with less testing” mentality; not an issue—it’s one iteration. Just don’t let that become the default answer to someone not completing an iteration’s work on time. Development can have unexpected speed bumps that delay delivery and acknowledging that and documenting what it was for future reference is important. Covering it up by reducing testing time risks a less stable product and does not help overcome the issue in the future.

So start thinking in terms of DevOpsTest. Make sure the product you are delivering represents the massive time investments you’ve made producing and maintaining it. You’re rocking it—and something like integrated testing ensures that users see how great you are rocking it and not an error page.

March 2, 2022
Shifting Engineering Priorities for 2022

Nearly every aspect of the software development process is accelerating, from the increasing speed of programming languages to the expectation of faster delivery. This has resulted in the misconception that speed and efficiency should be a DevOps team’s or engineer’s top priority. Though agile transformations have been a central strategy for most organizations in recent years, investing in team culture while undergoing an agile overhaul is paramount to overall success.

For many workers, the pandemic caused a shift in priorities, so much so that as we begin to emerge from the events of the last two years, almost a quarter of UK workers are planning job changes and businesses are tackling the so-called Great Resignation. A desire to improve work-life balance and enjoy better benefits like flexible working has made employees more likely to leave a job. As such, maintaining employee satisfaction and protecting team mental health should be a top priority for companies wanting to keep retention rates high.

This starts with leadership, and engineering and DevOps leaders must have full transparency into their teams, with an understanding of exactly what motivates them. With this in mind, here are three top priorities for engineering and DevOps leaders in 2022.

1. Prioritize Team Culture

The tech sector is notorious for a high employee turnover rate, with a LinkedIn report putting it at 13.2%, far above other industries. For engineers especially, the increased pressure to deliver at lightning speed has created an unsustainable “churn and burn” culture.

Simultaneously, engineers have no shortage of options when it comes to job prospects as demand is booming. In fact, this particular sector in England and Wales advertised more job vacancies in 2021 than all British businesses across 2020.

To avoid any leavers, it’s important for engineering leaders to establish a unique and engaging culture within their teams, and actively and continuously examine it to ensure that engineers feel supported and valued.

However, there are a few key principles shared across world-class engineering teams. Allowing engineers to work on projects that excite them and allow them to explore their creativity is crucial. This may involve giving them dedicated time to work on developing their skills and pursuing innovative projects. In addition, leaders should cultivate a culture for their engineering teams that is built around appreciation, collaboration and psychological safety. Weaving open and honest career discussion and satisfaction check-ins into one-on-one meetings will help employees feel listened to and motivated by their personal progression.

2. Use Data as Your Gut Check

Ensuring decisions are data-driven is also incredibly important. The best leaders are often those who use concrete evidence to strengthen their teams. Engineering leaders must use data and metrics to gauge the health of their teams in the current jobs landscape.

Even for engineering leaders, a team’s day-to-day programming can sometimes seem like a black box, so finding clear insights about the development process is imperative. With an engineering metrics solution, it is possible to obtain better visibility into your team’s workflow. This not only helps ensure efficiency and quality, but it can also help to gauge employee success and morale.

Continuous health monitoring using a robust set of metrics will provide leaders with early identification and help to resolve any friction. A data-driven platform to ensure that individuals’ contributions are ‘seen’ is fundamental. Monitoring a teams’ daily workflow helps to identify standout employees that may otherwise fly under the radar, as well as flagging those who may be struggling. It’s important to pay particular attention to metrics that drive employees toward their professional goals and help to remove bottlenecks across teams.

Prioritizing constructive feedback and one-on-one conversations with employees is crucial to employee success and retention. The focus must be on frequent check-ins with engineers to ensure that they are thriving personally and professionally.

3. Focus on People First, Rather Than Performance

Nothing will ever be as important within a team as the people. Only the engineering and DevOps leaders who prioritize people through a variety of tools and techniques will reap the rewards and stay ahead of the competition.

Recent research has shown that happy employees are up to 12% more productive.

An engineering team will deliver their best work when they feel encouraged by leaders, have the space and autonomy to work in a meaningful way and have accomplishments acknowledged and celebrated.

As leaders, it is critical to remember to check in with team members as people, before checking in with them as workers.

Engineering leaders will likely be battling for in-demand talent in 2022 and beyond as they continue to contend with the Great Resignation. In the face of this, there is a real opportunity for leaders to distinguish teams through their engineering culture. Whether you are cognizant of it or not, a team has a culture. It’s incumbent upon engineering leaders to make having a people-first culture the top priority in 2022.

March 1, 2022
Boosting DevOps Productivity Requires Visibility, Automation

Engineering teams continue to struggle with roadblocks and bottlenecks during the development process, according to Software’s recent 2021 Code Time Report.

The study, which is based on feedback from more than 250,000 developers using the Code Time plugin, found the median code time per developer is 52 minutes per day, or four hours and 21 minutes of code time per week.

The data also revealed that only about 10% of developers spend more than two hours per day coding, including on weekends, while about 40% of developers spend more than one hour per day coding.

The study also indicated developers are battling distractions that range from too many meetings and too many interruptions to too much wait time on processes and systems.

Distractions, Disruptions and Meetings Dog DevOps

The conclusion was most companies ineffectively deploy their development and DevOps teams, bogging down engineers with distractions, disruptions and meetings as well as system inefficiencies, such as slow reviews, slow builds and bad tools.

Software’s CTO Mason McLead said based on the company’s estimates, developers spend an additional 41 minutes per day on other types of work in their editors, such as reading code, reviewing pull requests and browsing documentation.

“The key to ensuring the highest levels of productivity from DevOps teams is visibility,” he explained. “We’re all biased toward focusing on what’s readily apparent, but the biggest bottlenecks are often hard to find and difficult to measure.”

McLead said by improving visibility across the entire development life cycle in a way that measures system-level metrics and not individual performance, DevOps teams can focus on the biggest constraint and have a more meaningful impact on their team’s productivity.

He said one example of a productivity metric with hidden barriers is lead time.

“I’ve spoken with many managers who disproportionately focus on how long it takes to review pull requests as a key lever to minimize lead time,” he said. “However, there are many stages in releasing a new feature that might actually be the key constraint—for instance, how long it takes to test and validate changes in a staging environment, or how long it takes to release merged pull requests to production.”

While these stages of lead time are all measurable, McLead explained most DevOps teams don’t have a data pipeline or BI tool set up to measure them.

He added that once an organization can diagnose the key constraint, it’s a lot easier to come up with an effective solution to minimize that constraint.

For example: If pull requests are taking a long time to create, are tickets being properly scoped? Can you see a correlation between the size of the pull request and the time it takes to be approved and merged?

McLean pointed out that if pull requests are taking a long time to be reviewed, it is critical to ensure proper expectations are being set.

He added it’s important to determine if there is a system in place to remind reviewers and enough time set aside in the day to perform the review.

“Taking steps to further automate deployment processes are another potential fix if it currently takes a long time to deploy a change to production,” McLead said. “It really all comes down to being able to measure the top constraint so that you know where to spend your time.”

Remote Work and Visibility

Remote work is also expanding the role of traditional DevOps teams: The trend toward more flexible working styles will demand more investments in DevOps such as secure provisioning of remote infrastructure, better access management and improved developer onboarding to better enable productivity for development teams.

“Visibility into how your DevOps investments are making an impact will play a big role in the decision on whether to stay remote or return to the office,” McLead said.

He added one way to attract and retain a highly productive DevOps team is to show that your DevOps investments are paying off.

“I recently talked to an engineering manager whose team wasn’t getting features out fast enough,” he said. “It took a month on average to complete a ticket, which had a significant impact on their ability to move major roadmap items forward.”

He explained that by implementing measures to improve throughput (e.g. investing in CI/CD, reducing build times and improving test coverage), they were able to decrease lead time from one month to four days.

By setting up a data pipeline and BI tool and increasing visibility, the engineering manager was not only able to report on metrics to his executive team and board with confidence, but also boost morale on his team.

From McLead’s perspective, retaining talented and trained DevOps engineers is critical because many DevOps projects require a longer timeframe in which to implement and measure their success.

“Highly effective DevOps teams measure not only how their investments are improving efficiency in the short-term, but also how changes in throughput and productivity are trending over months and years,” he said. “If your team is experiencing high turnover, it’s even more difficult to consistently deliver results over these longer time frames.”

March 1, 2022
How to Build an Effective API Security Strategy
Application Programming Interfaces (APIs) enable organizations to grow their businesses and drive innovation. APIs allow applications to easily transfer data to external third-party developers, business partners and internal departments. Since APIs have access to valuable and sensitive data, they have increasingly become a target for cyberattacks.

At the API Security Summit, taking place on March 3, distinguished cybersecurity leaders will discuss the top API security vulnerabilities to be on the lookout for and how to build an effective API security strategy.

The agenda for the API Security Summit will explore the following topics:
- The importance of API security testing
- The role of APIs in their environment
- How are hackers getting in? What can we learn from them?
- How API attacks are different from traditional application attacks
- What leading CISOs are doing today to protect themselves
- How APIs are increasing the attack surface
- Why API management is not enough for API security
- The benefits and limits of “shift left” tactics
- Ways to increase API security fluency across your organization
- How to drive automation across dev and security teams
The speaker lineup features top security experts, including:

Corey Ball, cybersecurity consulting manager at Moss Adams

Dr. Katie Paxton-Fear, lecturer of cybersecurity at Manchester Metropolitan University

Tom Salmon, head of cybersecurity at bp Launchpad

Nir Valtman, CEO at Arnica and former head of product security at Finastra

Tyler Warren, deputy information security officer at Prologis

Jeff Serota, principal security engineer at Ally Bank

Jack Hart, InfoSec professional and API security lead at City National Bank

David Biesack, chief API officer at Apiture

Curtis Simpson, CISO at Armis

Anthony Doerga, founder at AppyThings

For more information and to register, please visit the API Security Summit website.
February 28, 2022
What to Expect When Transitioning to DevSecOps
How do you ensure your DevOps pipeline is secure? Does DevSecOps protect you against serious breaches or is it just a way to allay the concerns of stakeholders about security in DevOps?

A data breach can cost an average of $3.92 million USD, as per IBM’s study Cost of a Data Breach. In this report, health care was found to be the most expensive industry, with breach fines averaging $6.45 million USD.

While DevOps delivers on the promise to increase the rate of delivery, the traditional CI/CD framework does not emphasize security. For the sake of speed, misconfigurations and known vulnerabilities may be allowed to pass through the development pipeline to production.

Security and testing are generally a low-priority activity, which means these vulnerabilities are fixed retroactively. This takes more time, effort and money. With rampant, unverified integration of open source tools, you open up the software to attackersthat could compromise the security of your apps, systems and users’ data.

DevSecOps is an upgrade to DevOps, allowing you to deliver security and compliance testing continuously. These checks get integrated within the CI/CD pipeline to enable the delivery of more secure code faster.

From DevOps to DecSecOps: What to Expect

The automated nature of DevOps delivers several benefits that enable teams to realize the true power of DevOps as silos break and delivery rates skyrocket.

As DevOps practices span the entire delivery pipeline, it provides the necessary mechanism to deliver audit, compliance and security requirements along with speed and efficiency.

There are many benefits of upgrading from DevOps to a dedicated DevSecOps practice, and they are important to understand before you embark on that journey.

1. No Restrictive Access Control Policies for Developers

Access to infrastructure assets must be strictly controlled and monitored to enforce requisite security measures. This means approval gates, secure configuration parameters and other security measures.

With DevSecOps built into the pipeline, these access controls can be automatically applied. This enables on demand access to infrastructure resources for the team and reduces their dependence on factors outside the team.

For example, many organizations have started deploying internal DevOps teams that enable automated access to a shared pool of deployment processes, tools, repositories, workflows, etc.

This team is usually separate from the IT team but enforces security mechanisms with the same rigor. It ensures that access to all the infrastructure instances required by development, QA or production is automatically tracked, monitored and controlled as per the guidelines. Additionally, inconsistent processes or misconfigurations are also controlled.

Often called the shadow IT team, the idea of this team is not to circumvent the IT department but to create an additional team that matches the agility of the DevOps team.

2. Seamless Security and Compliance Testing

Traditionally, security and compliance testing happened all at once at the end of the release cycle close to the release date. This typically meant that a large spreadsheet of issues is sent to the development team to be fixed immediately, since maintaining a consistent release velocity is the key to DevOps success.

This requires the development team have at least one dedicated resource to work on those issues. When metrics are tracked, to no one’s surprise, this method resulted in negative impacts on the velocity of the next release cycle.

DevSecOps applies all the security and compliance checks in batches. So, testing for security and compliance is shifted left and spread out across the pipeline.

This makes the security feedback loops shorter and more frequent, thus aligning security and compliance testing with the DevOps philosophy. As more secure code is committed every time, the possibility of security and compliance errors reported by the QA team is minimized.

A second, more personalized approach is using the integrated development environment (IDE) itself to take security and compliance checks to the developers. With regular and automated security and compliance baked right into the development process, this process is sped up considerably and the development team becomes self-reliant.

3. Overcoming the Risks Associated With Open Source Software

The 2019 State of The Software Supply Chain report from Sonatype showed that, on average, 85% of the codebase among modern applications uses open source components. While open source components enable innovation, they also come with considerable security risks. As more of these open source tools are added to the software supply chain, it increases the risks on the cybersecurity front.

The same report showed evidence to back up the need for greater open source software security checks and processes. Companies that managed their open source components released 55% less vulnerable components than those who had no verifiable open source management process.

While many of these open source components released frequent patches, it is also important for the DevSecOps team to step in and regulate the open source components. Some of the ways DevSecOps teams can do this are:
- Create a formal component management plan which makes sure that when employees leave, the practice doesn’t go away with them. Having a documented plan lets you look at the bigger picture of your pipeline and find vulnerable components that may be skipped without a formalized process. Incremental improvements to this plan are also possible if it’s well-documented.
- Use scanning tools like Gemnasium and Snyk that help regularly check for vulnerabilities.
- If vulnerabilities are detected or reported in a component, look at either updating or replacing the component.
- Enable quick approval for new open source software. Alternatively, prepare developers to test new components using security and compliance checklists.
4. Overall Cost Reduction and Acceleration of the Delivery Rate

An integrated security and compliance framework in DevOps prevents breaches and guarantees faster recovery when breaches do happen. As developers don’t have to set aside a large chunk of time to work on security and compliance violations, this shortens release cycles and ensures more secure code at the same time.

The fewer breaches you identify and fix, the more money you save on overcoming security disasters.

5. Automated Compliance Reporting

DevSecOps automates your security and compliance tests and it also logs and documents all the tests. DevOps automation platforms collect large amounts of information for the build, test, integration and deployment phases. This data can be used to create an end-to-end audit trail without any manual intervention or extra time spent scouring through various tools to prepare compliance reports.

A fantastic advantage of DevSecOps is the complete traceability from day one and automated compliance reporting. DevSecOps also focuses on the automation of testing, allowing you to deliver a secure development framework on a continuous basis.

DevSecOps is the Future of DevOps

The rapid release velocity DevOps enables is not without its disadvantages. In particular, the unchecked use of open source tools in the pipeline can expose your applications and systems to many known vulnerabilities, increasing the probability of a breach. Combined with a general lack of focus on security, this is a recipe for an expensive security incident.

To counter this, DevSecOps radically transforms the pipeline by shifting security and compliance testing left. Developers check the code before every commit. With fast feedback loops, they fix any reported vulnerabilities along with other errors in the app.

With DevSecOps, compliance and security checks are not done all at once; instead, developers chip away at vulnerabilities and security flaws with every release.
February 28, 2022
How SREs Benefit From Feature Flags

When you think of who uses feature flags, your mind most likely goes to software developers. In general, feature flags are closely associated with software engineering.

But site reliability engineers (SREs), too, can benefit. SREs may not be the ones to create feature flags, but they should work closely with developers to ensure that the applications their teams support include feature flags.

Here’s why feature flags benefit SREs, and what SREs can do to make sure their organizations take full advantage of them.

What Is a Feature Flag?

A feature flag—also sometimes called a feature toggle—is a technique in software engineering that allows developers to turn specific features on or off at application runtime. In other words, they let you control which features are available within your application when it’s deployed to production.

Feature flags can be configured in such a way that they enable features to be toggled on or off for specific sets of users, rather than an entire set of end-users. This is useful if, for example, you want to turn on an experimental new feature for users who have agreed to test it without exposing that feature to your general user base.

Usually, developers and SREs use feature flags to turn features on and off manually. But you could automate the process by, for example, writing a script that automatically shuts off a feature if your observability tools determine that the feature is causing a problem for users.

Why Developers Love Them

The main reason why feature flags are popular among developers is that they make it easy to implement and experiment with new features while keeping the development pipeline simple.

Without them, developers would have to create a new application release every time they wanted to implement new features. If any of the features in that release turned out to cause a problem, they’d have to remove the features from the code or fix the buggy features, then deploy a new release. This approach is tedious and it leaves teams prone to delayed releases and application rollbacks.

But with feature flags, developers can continuously add new features to an application without worrying that bugs within those features will lead to a rollback or a delayed release. If one feature has a problem, developers can simply turn it off using a feature flag, without having to do a new release.

How SREs Can Benefit

It’s not just developers whose lives are made easier—SREs, too, can leverage feature flags as a way of supporting the core SRE goal: Maximizing reliability.

That’s because feature flags minimize the risk associated with fast-moving software development pipelines. They allow teams to experiment with new application functionality—which is important if they want to keep pushing out application enhancements to delight users—while at the same time providing a safeguard against buggy feature implementations.

Imagine, for example, that you’re an SRE and you discover that the latest release of an application you support has a severe latency problem due to an issue with a new networking feature in the app. If that feature is controlled via a feature flag, you can remediate the issue very quickly by simply switching it off. You don’t have to wait for developers to fix the underlying code issue before you can solve the problem for your users.

Limitations

This doesn’t mean, of course, that feature flags are a cure-all against reliability problems.

They won’t help you if the root cause of your reliability issue lies within your infrastructure rather than your software. If an app crashes because you misconfigured your Kubernetes clusters or you ran out of server capacity, for instance, you can’t simply turn the problem off with a feature flag.

Note, too, that feature flags can only be applied to specific features. In other words, they can only control application functionality if developers deliberately created one to control that functionality before releasing the app. If you discover a bug that’s not managed by a feature flag, the only way to remediate the issue is to redeploy the application (or microservice, if the problem is limited to just one microservice).

How SREs Can Encourage Feature Flag Use

As an SRE, you most likely don’t have direct control over the software development process. You’ll therefore need to collaborate with developers to ensure that they build feature flags into their applications.

Doing this is simple enough. Start by educating developers and making sure they understand the benefits. Be sure, too, to identify which features are most likely to create reliability issues, so that developers can prioritize creating feature flags for them. And consider factoring them into your incident response playbooks, which will ensure that incident response teams remember to take advantage of them when possible to remediate issues quickly.

February 25, 2022