Programming Languages, SCM and Attacks
🎯 Concept Focus
In this article we go through
what language/runtime you’re using,
how the code gets built and executed,
how dependencies are pulled in,
whether environments are isolated,
and whether you can prove who changed what, when, and why.
If we keep the analogy of software as a high-speed rail network:
the programming language is the design standard (track gauge, signaling rules),
the compiler/interpreter is the train engine translating controls into motion,
SCM is the control tower and black box recorder,
SAST/SCA are inspection robots,
and XSS/CSRF/Injection are the “small cracks” that become derailments at scale.
Programming Languages:
The 5 “generations” in plain terms
1GL — Machine Language
Pure 0s and 1s.
Fast for the CPU, brutal for humans.
Security angle: low-level control, low-level mistakes; hard to review.
2GL — Assembly
Mnemonics like
MOV,ADD,SUB.Still close to hardware; needs an assembler.
Security angle: powerful and precise; also easy to create unsafe memory operations.
3GL — High-level languages
C, C++, Java, etc.
Needs a compiler or interpreter (or both in some models).
Security angle: abstraction helps productivity, but vulnerabilities scale quickly when patterns repeat.
4GL — “Do this” languages
Often used for DB queries, reporting, rapid application development.
Examples you cited: Perl, PHP.
Security angle: fast output, fast mistakes—especially around input handling and templating.
5GL — Constraint/logic/AI-oriented
Prolog, Mercury, and similar logic-based approaches.
Security angle: different attack surface; still inherits supply-chain and environment risks.
Assemblers vs Compilers vs Interpreters
Assemblers
Convert assembly → machine code.
Security impact: close to hardware = high blast radius for unsafe operations.
Compilers
Translate high-level code → machine code (often producing executables like
.exeor libraries like.dll).Runs the “translation” in one go and emits an output artifact.
Security impact: build pipeline becomes a critical trust boundary—if build is compromised, you ship compromised binaries.
Interpreters
Execute code line-by-line at runtime (Python, JavaScript, Ruby in your notes).
Slower, easier to debug, very flexible.
Security impact: runtime dependency loading, dynamic execution paths, and injection risks become more prominent.
Executive takeaway: in secure SDLC, “translation” isn’t a developer detail. It’s a control point.
SCM
Source Code Management (SCM) is the process and platform that controls, versions, and audits code changes.
If your organization builds software, your code repository is not a tool. It’s a high-value asset.
What SCM gives you (when done right)
Version control: rollback, traceability, comparison.
Collaboration: multiple engineers, one source of truth.
Security & integrity: prevents silent tampering.
Auditing & compliance: who changed what, when, and under which approval.
Key features (CISSP-friendly framing)
Accountability: identity and non-repudiation for commits/merges.
Integrity: only authorized change paths.
Verification: quality/security gates before deployment.
Reality check: “air-gapped repo” is the extreme option
Your notes mention the most secure model: isolating dev/test/QA in an air-gapped network and exporting to production via removable media. That’s valid in highly regulated or high-threat environments, but most modern orgs do a more practical approach:
hardened repo access + MFA
protected branches
signed commits/releases
CI/CD with mandatory checks
least privilege + separation of duties
Source Code Analysis Tools
These tools analyze source code to detect vulnerabilities early in SDLC.
Strengths
Scalable across many repos.
Great at known patterns: buffer overflows, SQLi, unsafe functions.
Developer-friendly output (file + line number).
Weaknesses
False positives (noise kills adoption).
Misses context-heavy issues (business logic flaws).
Doesn’t catch config/deploy weaknesses.
CISSP framing: automation helps, but it’s not governance. Your process must decide what gets fixed, when, and by whom.
SCA + FOSS
Software Composition Analysis (SCA) discovers open-source components and checks them for known vulnerabilities.
What it does well:
builds an inventory (dependencies + transitive dependencies),
flags known CVEs,
integrates in build pipelines.
Why it matters: attackers love known flaws in popular libraries because it scales. If you can’t answer “what versions are we running?”, you don’t have control—you have hope.
Malware basics + practical prevention
Malware is harmful software that can steal data, disrupt operations, encrypt systems, or take control.
Key points from your notes:
malware can damage data/programs and consume resources.
viruses are a large class of malware and typically require user action to spread (unlike worms).
Policy + training controls
Don’t execute email attachments blindly.
Describe attachments clearly when sending.
Reduce script execution surfaces (Windows Script Host, ActiveX, VBScript, JavaScript where appropriate).
Prefer plain text emails where feasible.
Use layered scanning (no single scanner catches everything).
Remember: antivirus is mostly reactive.
Control and separation of environments
Three environments are not bureaucracy. They are containment zones:
Dev: flexible, rapid iteration, limited access.
QA/Test: production-like, isolated, verification focused.
Prod: strictest controls; changes are heavily gated.
Why separation matters
prevents untested code from reaching users,
reduces accidental exposure of secrets,
constrains attacker movement when dev is compromised.
Web app greatest hits: XSS, CSRF, Broken Auth, Injection, Directory Traversal
XSS (Cross-Site Scripting) — client-side
Untrusted input is sent to the browser without proper escaping → attacker script executes in victim’s browser.
Stored XSS: saved on server and served to users.
Reflected XSS: payload delivered via URL/request.
DOM-based XSS: client-side DOM manipulation triggers execution.
Controls
input validation + sanitization
output encoding
CSP
escaping special characters
CSRF (Cross-Site Request Forgery) — server trusts the wrong request
Victim is logged in; attacker tricks their browser into sending an unwanted request.
Controls
CSRF tokens
SameSite cookies
re-auth for sensitive actions
origin/referer checks
confirmation pages
CSRF vs XSS
CSRF tricks the server into accepting a request.
XSS tricks the browser into executing a script.
CSRF = trust website has in user.
XSS = trust browser has in website.
Broken Authentication & Session Management
Weak auth/session controls allow account takeover:
session hijacking
credential stuffing/spraying
session fixation (not rotating session IDs)
Controls
MFA
kill default credentials
strong session IDs (entropy)
rotate session IDs after login
secure cookie handling
Injection flaws (SQL, OS command, LDAP)
Untrusted input reaches an interpreter → it executes unintended commands.
SQL Injection protection
prepared statements / parameterized queries
stored procedures (often the most effective when options combine)
input validation (whitelist)
least privilege DB accounts
limit query output (
LIMIT)
Insecure Design (not just bad coding)
This is a leadership concept:
security controls weren’t conceived in architecture/requirements.
fixing it requires revisiting design, not just patching code.
Prevention
Secure SDLC gates (ISO 27001 A.14 lens)
threat modeling for critical flows
reusable secure design patterns
security acceptance criteria in user stories
environment separation + segmentation
automated validation in CI based on misuse cases
Directory Traversal
Manipulate file paths (../) to access files outside web root.
Controls
avoid letting user specify paths
whitelist allowed files/extensions
predefined directory structures
strong input validation
Sandbox + Code Signing
Sandbox
An isolated environment where untrusted programs run with limited access.
Modern malware can detect sandboxing and sometimes evade or break out → sandboxing is strong, but not a silver bullet.
Code Signing
Verifies:
authenticity (who signed it),
integrity (not altered after signing).
Limits:
signed code can still be vulnerable,
doesn’t guarantee safe runtime module loading,
not DRM/copy protection.
🧠 Brain Ticklers
Q1) Neuromesh is tightening SDLC controls. Which control most directly supports non-repudiation in source code changes?
A. Enforcing SameSite cookies
B. Code signing production binaries
C. SCM commit history with authenticated identity and protected branches
D. Using an interpreter instead of a compiler
Q2) A web team reports a bug: a malicious script executes in users’ browsers after viewing a product review page. The payload persists for all visitors. What is the MOST likely issue?
A. Reflected XSS
B. Stored XSS
C. CSRF
D. Directory traversal
Q3) An attacker tricks a logged-in Neuromesh user into clicking a link that transfers funds. No script executes in the browser; the request is processed because the session is active. What is the BEST defense?
A. Output encoding
B. CSP headers
C. CSRF tokens
D. Disabling JavaScript
Q4) A security engineer wants to reduce SQL injection risk in a new service with minimal disruption to development velocity. What is the BEST primary control?
A. Validate input using a blacklist of bad characters
B. Prepared statements / parameterized queries
C. Allow only admin DB accounts to simplify access
D. Encrypt the database at rest
Q5) Neuromesh wants earlier detection of common vulnerabilities across multiple codebases, but developers complain about “too much noise.” Which statement is MOST accurate?
A. SAST finds only exploitable issues and should replace manual review
B. SAST is best late in production because it sees real traffic
C. SAST scales well but can generate false positives; tuning + triage is essential
D. DAST is always better because it reads source code
5 takeaways for busy readers
Language and execution model shape your attack surface; security is not language-agnostic.
SCM is a security control, not just collaboration tooling.
SAST catches patterns early; SCA catches dependency risk; neither replaces good design.
Environment separation is containment—without it, every mistake reaches customers.
XSS and CSRF are “trust abuse” attacks: one abuses browser trust, the other abuses server trust.
Follow the Series : Databases
#CISSP #CyberSecurity #InfoSec #SecurityLeadership #WomenInCyberforce #WomenInTech #AnyaInCyberSecurity #FromDevToDefender #TechLeadership #DevSecOps #CISSPDomains