It’s been said there are only two types of companies:

  1. Digital-first companies
  2. Companies undergoing digital transformation.

A digital-first company begins with a digital mind set and uses technology to solve its business or technology problems. Companies undergoing digital transformation are existing companies that have realized that technology is essential to survival in a rapidly evolving global economy.

Regardless of the type of company leaders find themselves in, they have to balance five pressures:

  1. Technology innovation – As newer technologies disrupt existing models, new paradigms evolve. There is always a fear of being irrelevant in business.
  2. Competitive pressure – Direct competition is a constant threat to business. At the same time, indirect competition and business models continually evolve, creating an endless cycle of challenges.
  3. Uncertainty about the future – Information overload leads to “analysis-paralysis.” Overwhelmed by news and biased reports, it is very difficult for executives to choose the right investments. Continually evolving markets create more uncertainty, complicating the decision-making processes.
  4. Regulatory Pressure – Increasingly complex laws, rules, and regulations make it difficult for businesses to keep up. Businesses find themselves caught between regulatory requirements and the constant need to grow revenue in competitive markets.
  5. Cyber threats – Cybercrime has become a global industry, impacting organizations in every part of the world. State-sponsored cyberattacks have also become more common, raising the stakes for all companies, at every level of the economy.

Technology and security leaders must balance all these competing pressure points. Securing systems and software for digital-first companies and companies undergoing digital transformation remains an ongoing and ever-present challenge, bringing to mind the famous quote from Pythagoras: “Step not beyond the beam of the balance.”

From Automation to Hyperautomation

Technology will not solve all of your security problems, but it will solve many of them. Regardless of what stage your organization is in, assuming a “technology first” attitude will be helpful. The intelligent use of technology is truly the key to creating and sustaining a successful security program. In the following pages, we look at some of the security challenges facing digital-first startups and established organizations in the midst of digital transformation, and we suggest steps for mitigating security problems.


As a startup, you are primarily focused on the needs of your alpha and beta customers. Depending on the business you are in, rapid quality iteration is imperative. Regardless of your offering – whether it’s software or a hardware tool or an online business – it’s not uncommon for security to be overlooked. It’s quite possible that your software engineers do not have a security background, and that your company doesn’t have a formal security plan. That said, you have an obligation to your customers and to their customers. Your offering cannot compromise the security of their systems or their information. Fulfilling this obligation begins with securing your software.

 So, how should you go from zero to one? Here’s an example from my own experience:  I had joined as the first security executive at a healthcare startup. Given that the company would need to demonstrate strong security controls to potential customers, I made the case to leadership that HITRUST compliance should be a top goal for the first year. With the budget for that initiative, I was able to set up a fully functional security program, complete with policies, procedures, implementation, measurement, and management by the end of the first year across all the 19 domains – from access controls through application security to even physical security of the company in one fell swoop.

My insight from this experience is that you need to discover the top business priority and determine which part of the security story will garner company-wide support. Then you must move forward swiftly and accomplish your goal. Here is some specific practical advice:

1. Automate Patch Management and Configuration Management

  • Use the latest version of open source code for the tools your team is using.
  • Invest in automating patch management immediately.
  • Regression testing

2. Run open source security tools. Most of the problems that you would encounter are run-time problems. Running ZAP is one of the ways you can immediately check the security of your software :

3. Look at the security defects and ensure they are fixed.

4. If you are using SaaS, use an open source external vulnerability scanner to begin with; OWASP has a good list. Try a few tools, and use them to check and fix vulnerabilities. Here’s the link to OWASP list :

5. Deciding what to fix can be confusing. Basing your priorities on risk is usually the best course.

6. Once the tactical issues are solved, it's highly recommended to create a robust security plan that includes more than software. Use a standard framework. Here’s a link to a framework from the Center of Internet Security (CIS) : . These 20 controls can help solve 97% of attacks.

7. Run CIS benchmarks for your platforms. Develop and test system hardening practices based on the benchmarks and results from the CIS-CAT Scoring Tool.

8. Based on your customers, SOC 1 or SOC 2 certifications or PCI or HIPAA might be required. Talk to your compliance experts and let them help you determine the best approach.

Companies Undergoing Digital Transformation

Large organizations are usually split into multiple business units, each focusing on different business functions. Executives reorganize themselves to gain efficiencies in business, seldom paying attention to the underlying system.

For example, some systems belonging to a particular business unit move to other part of the company after a reorganization. This causes churn in the organization, which can lead to security issues. When systems change hands, it’s difficult for new teams to take over the old systems and technology. Leaders tend to manage these kinds of situations by relying on expert talent. The problem, of course, is that relying on a handful of subject matter experts is not a scalable strategy.

The CIO or CTO of a corporation will strive to align the technology organization with the company’s business and product functions. But different business units often have their own technology stacks. Additionally, different units and groups may follow different release calendars and use different coding practices, different tools, different programming languages and different forms of code review. They may also be on different levels of the CI/CD maturity curve.

In a perfect world, all of the company’s units and functions would use the same platform. As the CISO or executive in charge of application security, one of your top goals is ensuring consistent security quality across different teams. This is not a trivial matter – as we all know, security is only as good as the weakest link.

As CISO or security leader, one of your first steps will be looking for these variations. As you might suspect, these variations may not be visible immediately. A positive initial step is to embed tools that will give you greater visibility into the CI/CD pipeline.

Examining various stages in the pipeline creates visibility. Deploy your teams to check the stages of the CI/CD pipeline in each business unit. I compare this process to the kinds of exams your physician performs when you go in for a checkup. Instead of checking blood pressure and heart rate, however, your security team will be performing:

       a. Read only static analysis tools

       b. Read only software component analysis

       c. Read only dependency checks

       d. Secrets detection

After thorough analysis, the next step is building a company-wide platform, containing libraries that can be updated and security guard rails that can be enforced. Here are problems to watch out for:

  1. Code reviews are not done properly or at all
  2. Sensitive material is hard coded in the code and developers continue with it
  3. Security defects are ignored
  4. Engineer identification
  5. Catalog defects based on criticality

And here’s some practical advice:

  1. Don’t reach out to engineering teams immediately when you spot a problem. Don’t eliminate the possibility that it could be a false positive. Too many false positives and defects will turn off engineers and they won’t cooperate. Best to ensure there are no false positives and then collaborate with one or two engineers to see if this is truly a defect. It won’t hurt to test it out first in your team before reporting a defect.
  2. Create a prioritized list of defects
  3. Fix critical defects. This is the time to reach out to the engineering leader and request help.  
  4. Give as much data as possible with line numbers and evidence of the defect.

Security is a business problem and a business-enabling function. Consider implementing compensatory controls if the team can’t fix issues at the speed of business. This can include putting web application firewall (WAF) rules into effect or using monitoring mode.

Starting with Waterfall

Your organization might still be using Waterfall (or Waterfall camouflaged as Agile) methodologies. Some project managers or program managers may claim they are using Agile or some variation of it, but when you dig a little deeper, you discover they are following a Waterfall methodology.

You also may find manual processes, such as authority to operate (ATO) that include human intervention at every step. Or you may discover that parts of your supply chain, some of your third-party vendors and even silos within your own company are using Waterfall. At the same time, you may be dealing with other constraints, such as a limited talent pool or inadequate technology tools and processes.

It’s also important to remember that your company’s teams may be large and geographically dispersed, using different technologies, different languages and different platforms. And of course, there will almost always be legacy systems of one kind or another to contend with. This is the nature of the modern enterprise.

In any event, your role is securing software, despite the challenges, while adapting rapidly to challenges created by changing conditions, both internally and externally.

Taking the Organization from Zero to One

As a security leader, it’s absolutely essential that you are perceived as a partner, rather than as a consultant. The ability to become a trusted partner is critical for all security professionals, regardless of the stage you are in. Establishing and maintaining trust is an ongoing process, not a once-and-done affair. It takes time and energy, but it’s worth the effort.

Defining your core principles is part of the trust-building process. Will you build or buy? If you build, will you build on open source? Will you strive to avoid vendor lock-in? Will you use native systems offered by a vendor?  

Regardless of the answers to above questions, it’s advisable to create a secure technology stack. Then application teams can continue to build their applications using their favorite languages and using their favorite systems on this technology stack.  

Here is some specific practical advice:

  1. You can’t defend terrain that you don’t know or don’t know that you own. Have a clear map of assets. Create a repository of all secure and approved containers and APIs. Use service discovery, access control, and everything that comes with it.
  2. Bake zero trust into the platform and containers with behavior detection all the way to the container level or function level.
  3. Leverage a scalable microservices architecture with mesh technologies and embedded security.
  4. Aim for automated centralizing logging and monitoring as a platform so that machine learning can be run on those logs.
  5. Platform and containers that are baked with zero trust and behavior detection should also have hooks for continuous scanning, alerting, CVE and CWE scanning.
  6. Make sure you have integrity controls to detect and prevent unapproved changes.
  7. If the organization wants to mature to a level to have STIG compliance, consider using Open SCAP.
  8. Insist on circuit breakers and self-healing as these are essential tools to contain any security attacks.
  9. Evaluate East-west traffic in addition to North-South traffic.
  10. Having TLS inside by default while monitoring traffic is highly recommended. Key management in such cases can be handled with some open source tools and commercial tools.
  11. Enable enterprise guardrails to detect if any of the teams/groups are deviating from standards.
  12. Automate to the next level and have ruthless focus on automation.
  13. The importance of patch management can’t be overstated. Invest in having a scheme to do A/B testing for automated patches and regressions so that patches are managed on a continuous basis.
  14. Make sure that the source code repository is appropriately protected. Source code on the internet with little access control and embedded secrets is highly exploitable. Having proper access control to source code inside and outside your premises is fundamental to securing software.

Food for Thought

  • Consider positioning your security initiative as a time-to-market efficiency play. That way, it’s a win-win for everyone.
  • No need to find only one pattern with DevOps. It’s OK to have multiple different systems if the cost of migration doesn’t outweigh the cost of optimizing a different solution – one size doesn’t fit all.
  • Try to build in automation to enable continuous security.
  • Since infrastructure and configuration is also code, consider a holistic approach to securing software, with infrastructure and configuration part of a continuous security process, by inventorying assets and protecting any changes to them using proper access control.

Migrating from Zero to One

Here are some tips and advice to consider for moving forward effectively with your essential security initiative:

  1. First, create an interceptor (such as a jar file, spring filter, side-car proxy or generic proxy) that won’t cause much latency.
  2. Then, add a new service with its own database and other supporting infrastructure and link it to the proxy. Implement the first new page in this service; then allow the proxy to serve traffic to that page.
  3. Add more pages, more functionality and potentially more services. Open up the proxy to the new pages and services. Repeat until all required functionality is handled by the new stack.  The monolith no longer serves traffic and can be switched off.


     A. Consider creating a separate group to offer Managed DevSecOps-as-a-Service to the organization.

     B. Assemble people from various teams into this Managed DevSecOps-as-a-Service team.


     A. Embed approval and security metrics in the Authority to Operate (ATO) process and use that as a gating factor.

     B. Train employees in various organizations with self-learning capabilities to bring in state-of-the-art “Securing Software” discipline.

     C. Incentivize organizations by making security as a part of their goals and use “Wall of Fame” or alternatively “Wall of Shame” methodology depending on the organization culture.


No two companies are alike. Even steady-state companies have differences. In some companies, the CISO is seen as the executive who is responsible for compliance. You might often hear, “Just do enough to make us compliant.”

If you are entering this kind of environment as a CISO, my advice is to make sure the executives get what they want first, and build your credibility over time. By all means, make sure the company is compliant. During the audit process, keep track of what the auditors discover and document their findings. This documentation will come in handy when you are making the case for more investment in security.

Identify the vulnerable points in your business and technology. If you are a B2C player, how do customers engage with your systems? If you are B2B or B2E player, how do customers integrate with your systems? How do employees, contractors and third-party vendors interact? Are the company’s customer support agents, employees or contract workers?

All these questions can help identify where the weakest links might be in the organization. Once you find vulnerable points, secure the funding to put detection tools in place. These tools might raise some concerns, or they may give you peace of mind. If the situation is genuinely bad, the tools will help you make the business case for more investments. If situation is not so bad, look for the second-weakest link. Investing in proprietary detection tools, or finding the right kind of open source detection tools, is a good step on the road from zero to one.

Executive Perspective(s)