DEV Community: Gopi Narayanaswamy

Building Secure Software in the Age of AI Coding Assistants

Gopi Narayanaswamy — Sun, 02 Aug 2026 13:23:34 +0000

AI can generate code in seconds. It can't own your security posture.

Introduction

Over the last two years, AI coding assistants have fundamentally changed software development.

Developers can scaffold APIs, generate tests, write SQL queries, refactor legacy code, and even build complete applications from a simple prompt.

This shift is increasing productivity across the industry.

However, there's one misconception that needs to be addressed:

Faster code generation does not mean secure software.

As engineers, we still own the architecture, the security decisions, and ultimately the risk.

AI Doesn't Understand Your Business

An AI assistant can generate authentication code.

It doesn't know:

Your threat model
Regulatory requirements
Customer data sensitivity
Internal security policies
Multi-tenant architecture
Compliance obligations
Zero Trust principles

These decisions still require experienced engineers.

The New Security Risks

AI-generated code often introduces subtle problems.

Authentication Mistakes

Generated examples frequently:

Skip authorization checks
Use insecure JWT validation
Trust client-side data
Ignore session invalidation

These issues rarely appear during happy-path testing.

Dependency Risks

Many generated projects include:

npm install ...

without considering:

vulnerable libraries
abandoned packages
supply-chain attacks
transitive dependencies

Always verify dependencies before production.

Hardcoded Secrets

Developers sometimes copy generated examples containing:

API_KEY="xxxxxxxx"

DATABASE_PASSWORD="password123"

Never commit secrets.

Use:

Secret Manager
AWS Secrets Manager
Azure Key Vault
HashiCorp Vault

Missing Validation

Generated APIs frequently trust incoming requests.

Every API should validate:

input length
data types
allowed values
file uploads
request size

Never trust client input.

Excessive Permissions

Cloud examples often recommend broad IAM permissions because they're easier to demonstrate.

Production systems should follow the Principle of Least Privilege.

Security Should Start During Design

Before writing code, ask:

Who are the users?
What data is sensitive?
What happens if this API is abused?
What if credentials leak?
Can attackers enumerate resources?
What happens if a dependency is compromised?

This exercise is called threat modeling, and it often prevents vulnerabilities before a single line of code is written.

Secure Development Checklist

Before merging code, verify:

Authentication implemented correctly
Authorization enforced
Secrets stored securely
Dependencies scanned
Static analysis completed
Input validation present
Security headers enabled
Logging implemented
Error handling reviewed
Rate limiting configured

These checks should become part of your CI/CD pipeline.

AI Makes Great Developers Faster—Not Careless

AI is an incredible engineering accelerator.

But it should augment developers, not replace engineering judgment.

The most successful teams combine:

AI-assisted development
Secure coding practices
Automated security testing
Code reviews
Threat modeling
Continuous monitoring

That combination delivers software that is both fast and secure.

Final Thoughts

The future of software engineering isn't about choosing between AI and security.

It's about integrating them.

AI can help you write code.

Experienced engineers ensure that code is resilient, maintainable, and secure.

If you're adopting AI-assisted development in your team, treat security as a first-class engineering discipline—not as a final checklist before release.

About the Author

I work with organizations to design and build secure software, AI-enabled applications, cybersecurity platforms, and cloud-native solutions. My focus is on integrating security into every stage of the software development lifecycle, helping teams ship faster without compromising resilience.

Why Most External Attack Surface Monitoring Tools Miss 40% of Your Internet Footprint

Gopi Narayanaswamy — Sun, 02 Aug 2026 07:30:57 +0000

When security teams think about External Attack Surface Management (EASM), they often imagine a simple inventory of internet-facing assets:

Domains
Subdomains
SSL Certificates
Open Ports

Unfortunately, that's only a fraction of the real attack surface.

Modern organizations continuously expose new digital assets through cloud deployments, SaaS platforms, acquisitions, developer environments, marketing campaigns, and forgotten infrastructure.

The result?

Your internet footprint is always changing.

Attackers know this.

Many organizations don't.

What Actually Makes Up an External Attack Surface?

An organization's external attack surface includes far more than its primary website.

Examples include:

Primary Domains
Subdomains
Wildcard DNS Records
Expired SSL Certificates
Cloud Storage Buckets
Public GitHub Repositories
Internet-facing APIs
VPN Gateways
Employee Portals
Third-party SaaS Applications
Development Environments
Staging Servers
Forgotten Legacy Systems
Brand Impersonation Domains
Typosquatting Domains
Mobile Application APIs

Every exposed asset becomes another potential entry point.

Why Asset Inventories Become Outdated

Infrastructure changes constantly.

Developers deploy new environments.

Marketing launches microsites.

Cloud teams create temporary workloads.

Business units purchase SaaS applications without security involvement.

Within weeks, the official asset inventory becomes inaccurate.

Security cannot protect assets it doesn't know exist.

Passive Discovery

Passive discovery gathers intelligence without interacting directly with target systems.

Common data sources include:

Certificate Transparency Logs
DNS Records
WHOIS
ASN Information
Search Engines
Public Code Repositories
Internet Search Engines
Historical DNS Data

Passive discovery is safe, fast, and suitable for continuous monitoring.

Active Discovery

Passive intelligence isn't enough.

Active discovery validates whether discovered assets actually exist.

Typical techniques include:

DNS Resolution
HTTP Probing
TLS Inspection
Port Scanning
Banner Identification
Technology Fingerprinting
Redirect Analysis

Active validation removes stale assets while identifying live services.

Beyond Subdomain Enumeration

Many organizations stop after discovering subdomains.

That leaves enormous visibility gaps.

A mature attack surface program should also monitor:

SSL Certificates

Questions worth asking:

Which certificates expire soon?
Are weak ciphers enabled?
Which certificates were recently issued?
Brand Monitoring

Attackers frequently register domains similar to legitimate brands.

Examples include:

company-login.com

company-support.net

cornpany.com

company-security.co

These domains are commonly used for phishing campaigns.

Email Security

Evaluate:

SPF
DKIM
DMARC
MX Records
Mail Server Configuration

Misconfigured email remains one of the easiest attack vectors.

DNS Security

Monitor for:

Dangling Records
Subdomain Takeover
Zone Changes
DNS Hijacking
Unauthorized Records
Cloud Assets

Don't forget:

AWS
Azure
Google Cloud
Kubernetes
Object Storage
CDN Endpoints

Cloud environments evolve much faster than traditional infrastructure.

Continuous Monitoring Matters

A point-in-time assessment quickly becomes obsolete.

Continuous monitoring enables security teams to detect:

Newly exposed assets
Certificate changes
DNS modifications
Technology changes
New services
Suspicious domains
Infrastructure drift

This dramatically reduces the window between exposure and remediation.

Building an Internal EASM Platform

Many organizations build internal capabilities using open-source tools.

Typical architecture:

Scheduler

↓

Asset Discovery

↓

DNS Analysis

↓

Certificate Analysis

↓

HTTP Validation

↓

Technology Detection

↓

Risk Scoring

↓

Alerting

↓

Dashboard

Python works well for orchestration and data processing, while Rust or Go are strong choices for high-performance network scanning and concurrent discovery.

Challenges at Enterprise Scale

As environments grow, teams often encounter:

Millions of DNS records
Thousands of domains
Hundreds of cloud accounts
Multiple business units
Frequent acquisitions
Hybrid infrastructure
Remote workforce
Third-party dependencies

Managing this manually becomes impractical.

Automation becomes essential.

Key Takeaways

External Attack Surface Management is not just about finding subdomains.

An effective program continuously discovers, validates, enriches, and prioritizes internet-facing assets across cloud, applications, identities, email, DNS, certificates, and brand exposure.

Security begins with visibility.

Without complete visibility, organizations are defending only part of their environment while attackers search the rest.

Additional Resources

If you're interested in practical architectures for continuous attack surface discovery, certificate monitoring, DNS security, digital risk protection, and enterprise cybersecurity engineering, SG2 Technologies regularly publishes technical articles and implementation guides:

👉 https://sg2technologies.com

Where exactly is your sensitive data right now?

Gopi Narayanaswamy — Sat, 02 May 2026 11:53:25 +0000

Most enterprises can't answer this one question:
"Where exactly is your sensitive data right now?"
Not approximately. Not "probably in the data warehouse." Exactly.
If you paused before answering — you're not alone. 80% of enterprise data is unclassified or sitting somewhere it shouldn't be. And regulators under GDPR, India's DPDP Act, and HIPAA don't accept "we didn't know" as a defence.
That's the exact problem MetaSight was built to solve.
MetaSight is SG2 Technologies' enterprise data governance platform that gives you:
✅ Automated data discovery across cloud, on-premise & SaaS
✅ End-to-end data lineage — know where every record came from
✅ Sensitive data classification (PII, financial, health data) mapped to your compliance framework
✅ Stewardship workflows, access governance & audit-ready reporting
No more manual inventories. No more stale spreadsheets. No more compliance surprises.
We've delivered data governance across 20+ enterprise projects in India, UK, US, Australia, Singapore and UAE — with a 98% client satisfaction rate.
📖 Read the full breakdown of how MetaSight works and who needs it right now:
👉 https://gopithecheetah.github.io/metasight-dg/
Or reach us directly:
📧 info@sg2technologies.com
📞 +91 77082 33529
If your organisation can't answer "where is your sensitive data?" with confidence — that's where we start.

Mobile Charging cable – Can be an EVIL, Can Send Data to a Remote Attacker

Gopi Narayanaswamy — Tue, 14 Sep 2021 12:40:19 +0000

A new and upgraded version of a malicious Lightning cable that can steal user data and remotely send it to an attacker illustrates the threat of untrusted accessories.

Security researcher Mark Green, (who goes by MG) has revealed to the Vices team at Motherboard that he and his team have upgraded their version of a hacked Lightning cable in a way that allows a hacker to record keystrokes and then to send the data to a designated site. This would allow the device to be used to steal passwords and other sensitive information.

The OMG Cable, which looks exactly like a standard lightning to USB cable, was first demoed back in 2019 by security researcher MG. Since then, MG was able to work with cyber security vendor Hak5 to mass-produce the cables for researchers and penetration testers.

It can hack both Android, Apple devices and hack your systems

If you have a device and you plug it in there, there's a possibility that your confidential information will be hacked. The data will be sent to the remote attacker.

There are USB charging cable with IP Address included also a vulnerable to attackers and can be operate from miles away. The attackers can exploit the user's device by obtaining their data when the cable was connected.

So please aware, while borrowing USB cable from someone or charging in a public place

Azure AD - Access On-Prem Web Application with Secure Remote Access

Gopi Narayanaswamy — Tue, 14 Sep 2021 12:35:44 +0000

Assume you have web application which is deployed in on-prem and you decided to the web application access with Multifactor authentication and accessed securely by remote users

Here is the solution with Azure AD, Azure Active Directory's Application Proxy provides secure remote access to on-premises web applications. After a single sign-on to Azure AD, users can access both cloud and on-premises applications through an external URL or an internal application portal. For example, Application Proxy can provide remote access and single sign-on to Remote Desktop, SharePoint, Teams, Tableau, Qlik, and line of business (LOB) applications.

The Application Proxy offering includes a cloud service and an on-prem connector. The cloud service, called the Application Proxy Service, works with the Application Proxy Connector, which runs on an on-prem server, to securely pass user sign-on tokens from Azure AD to the on-prem web app being accessed.

Application Proxy works with:

· Web applications that use Integrated Windows Authentication for authentication

· Web applications that use form-based or header-based access

· Web APIs that you want to expose to rich applications on different devices

· Applications hosted behind a Remote Desktop Gateway

· Rich client apps that are integrated with the Microsoft Authentication Library (MSAL)

How Application Proxy works

After the user has accessed the application through an endpoint, the user is directed to the Azure AD sign-in page.

After a successful sign-in, Azure AD sends a token to the user's client device.

The client sends the token to the Application Proxy service, which retrieves the user principal name (UPN) and security principal name (SPN) from the token. Application Proxy then sends the request to the Application Proxy connector.

If you have configured single sign-on, the connector performs any additional authentication required on behalf of the user.

The connector sends the request to the on-premises application.

The response is sent through the connector and Application Proxy service to the user.